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ABSTRACT 



Data are pushed from a source to a destination via an 
intermediate computer system. If the intermediate computer 
system is unable to forward the pushed data to the destina- 
tion for a predetermined length of lime, the intermediate 
system deletes the pushed data and never forwards the data 
to the destination. According to another aspect, the interme- 
diate system receives a command, e.g. from a server origi- 
nating the data, to delete the data if the data has not yet been 
forwarded to the destination. According to another aspect, 
the intermediate system receives data whose identifier (e.g. 
source URL) matches an identifier of data pushed earlier to 
the same destination but not yet forwarded. The intermediate 
system deletes the earlier pushed data and never forwards 
the earher pushed data. 

17 Claims, 13 Drawing Sheets 

Microfiche Appendix Included 
(25 Microfiche, 1323 Pages) 
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PUSHING AND PULLING DATA IN In some embodiments, the method further comprises the 

NETWORKS destination DEI pulling the data that has been pushed to the 

destination but deleted at the intermediate computer system. 

COPYRIGHT NOTICE goj^e embodiments, the destination DEI is a mobile 

A portion of the disclosure of this patent document ^ device, 

contains material which is subject to copyright protection. The present invention provides a method for processing 

The copyright owner has no objection to the facsimile data pushed over a network from a source or sources to a 

reproduction by anyone of the patent document or the patent destination or destinations via a computer system interme- 

disclosure, as it appears in the Patent and Trademark Office diate between the source or sources and the destinations, 

patent file or records, but otherwise reserves all copyright wherein the intermediate computer system communicates 

rights whatsoever. with the source or sources and destination or destinations 

over the network, the method comprising: the intermediate 

APPENDICES computer system receiving data being pushed to a destina- 

Tbeapplicali0DincludesAppendices,l,2,3,4.5,6,Al, ,s .""Vw T*^'."? computer system receiving a 

A2. B, C D, E. F. and G. Appendices B. C. D. E. F. and G f^'^'^f^ ° d^^t* "l* data if Ihe data has not yet been 

are microfiche appendices. Appendix B contains one sheet ^'^^f"^'' desunat.on DEI; ^ the data has not yet 

of microfiche. 7 frames. Appendix C contains one sheet of ''f'" forwarded to the destinatoon DEI. then the mtermedi- 

microfiche, 13 frames. Appendix D contains one sheet of .f computer sj^tem deletmg the data and never forwardmg 

microfiche. 3 frames. Appendix E contains two sheets of jo '° destmation DEI. 

microfiche, 151 frames total. Appendix F contains Sections I" some embodiments, wherein the command is received 

1, 2 and 3. Section 1 contains seven sheets of microfiche, °vef network from a source that was pushing the data. 

421 frames total. Section 2 contains seven sheets of The present invention provides a method for processing 

microfiche, 421 frames total. Section 3 contains four sheets data pushed over a network from a source or sources to a 

of microfiche, 196 frames total. Appendix G contains two 2S destination or destinations via a computer system interme- 

sheets of microfiche. 111 frames total. diate between the source or sources and the destination or 

destinations, wherein the intermediate computer system 

BACKGROUND OF THE IIWENTION communicates with the source or sources and destination or 

•me present invention relates to networks, and more destinaUons over the network, the method comprising: the 

particularly to pushing and puUing data over networks. 3° mtermediate computer system receivmg data DAI being 

^ ..... 7 , ^ pushed to a destination or destinations, wherem the pushed 

Anetwork chent receives data from a senrer by meansof ^^^^ ^^^^^^^ ^„ y^^u^g^ identifying a source of the 

a push or a pull In a pull, the client requests data from the pushed data; if the identifier of the pushed data DAI matches 

server. In a push, the seiver sends data to the chent without ^ ygn,;^^^ ^j,,^ p^^^ g^ji^, ^^ ^^^^ destination or 

the chent requesting the data. destinations but not yet forwarded to at least one of its 

An example is provided by a World-Wide Web (WWW) destination or destinations, then the intermediate computer 

browser Netscape Navigator, version 1.1, available from system deleting the earlier pushed data and never forwarding 

Netscape Communications Corporation of California. See the earlier pushed data to the destination or destinations, 

the WWW document http;/Avww.netscape.com/assist/net embodiments, the data DAI is a more recent 

sites/pushpulLhtml This browser runs on a chent network ^ ^^^^^^ ^^^^ ^^^ier pushed data, 

station. With this browser, the client can pull data from a „ . . . , , , , 

server. Alternatively, the client can allow the server to push present invention provides a method for operatmg a 

data. To allow the push, the cUent opens a network connec- ^^'^^{^ P'°^"'« °T ^ "^"'"'^ 

Uon (TCPAP connection) to the server and leaves the con- '°8; the server pushing data to a data destination or desa- 

nection open. Tlie server pushes data over the connection. ^'"'"'6 the data over the network to an interme- 

nie server can push new data blocks any time. TTie con- '^^'^ '^r'''"!' ^J?''"^'".^'' ? '° 'I"" '^^ 

nection stays open. The pushed data are immediately dis- '° data destinatioii or destmations; and the 

olaved by the browser server sending a command to the intermediate computer 

* ^ J „ ^ . . system to delete data which the server pushed eariier, the 

It is desirable to provide push and pull techniques that ^^mmand being a command to delete the data if the data has 

would make it faster for the client to access data from the 50 not yet been forwarded to its destination, 

server and would reduce the use of network resources. , , ,. , ^ . . . . 

In some embodiments, at least one or the destinations 

SUMMARY OF THE INVENTION whose data are to be deleted if not yet forwarded is a mobile 

device . 

Ihe present invention provides a method for processing ^ . . . , 

data pushed over a network from a data source or sources to 55 P'^'^"' " '"7." programmed to 

a data destination or destinations via a computer system P*f^°™. following operations: pushing data to a data 

intermediate between the source or sources and the desii- desunauon or destinations by sendmg the data over a 

nation or destinations, wherein the intermediate computer !° "»te™ediate computer system which is to 

system communicates with the source or sources and des- data over the network lo the data destmatioii or 

Unation or destinations over the network, the method com- 60 desUnaUons; and sending a command to the intermediate 

prising the intermediate computer system receiving data '^ompul^x system to delete data which the server pushed 

being pushed from a data source to a data destination DEI "''f - "jf command being a cornmand to delete the data if 

if the intermediate computer system is unable to forward the "^^^ ^as not yet been forwarded to its desunation. 

pushed data to the destination DEI for a predetermined The invention also provides suitable computer circuitry 

length of lime, then the intermediate computer system 65 and computer readable media. 

deleting the pushed data and never forwarding the pushed The present invention provides push and pull techniques 

data to the destination DEI. that reduce the use of network resources and make it faster 
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for the client to access data from the server. In particular, in FIG. 7 is a schematic diagram of a process for a server 

some embodiments, the client does not have to keep a side protocol station machine. 

connection open to allow pushes. Data can arrive at the piG. 8 is a schematic diagram of a process for sending 

client not over any connection opened by the client, but over notification to a client 

a connectionless link (i.e. as datagrams), or over a connec s j ^ schematic diagram of the structure of a LSROS 

tion opened by the server or some intermediate station, or invoke PDU 

over a combination of connectionless links and connections , , ^, 

opened by the server and/or an intermediate station or ^I^. 10 « a schematic diagram of the structure of a 

stations. If connection links are used, the connections can be Hequest FU U . 

closed after transmitting the pushed data. Therefore, the use lO FIG. 11 is a schematic diagram of the structure of a 

of connections, which are valuable resources in some Start-up PDU. 

networks, is reduced. FIG. 12 is a schematic diagram of the structure of a Sync 

Further, the client maintains a data cache for caching both PDU. 

pushed and pulled data. Pushed data are stored in the cache, FIG. 13 is a schematic diagram of the structure of a Notify 
but are not necessarily provided to the user immediately. 15 pDU. 

Rather, the pushed data are provided to the user when the piG. 14 is a schematic diagram of the structure of a 

user requests the data. Thus, the server can push data in LSROS Result PDU. 

advance of the user requesting the data When the user ^5 ^ schematic diagram of the structure of a 

requests the data, the data are already m the cache. Hence, RequestReply PDU 

the data arc accessed faster. Further, the user sees no ^ , . 

difference between the pushed and pulled data with the ^ FIG. 16 is a schematic diagram of the structure of a 

exception of latency— the pulled data take longer to access StartupReply PDU. 

if the data are not already in the cache. FIG. 17 is a schematic diagram of the structure of a 

In some embodiments, the cache is maintained on a SyncReply PDU. 

least-recently-used (LRU) basis. FIG. 18 is a schematic diagram of the structure of a 

Reduced latency makes the invention suitable for wireless NotifyReply PDU. 

networks which often have higher latency than wired net- FIG. 19 is a schematic diagram of the structure of 

works. In some embodiments, clients are handheld devices, Redirect PDU, 

for example, cellular telephones. The cellular telephones run FIG. 20 is a schematic diagram of the structure of KSROS 

WWW browsers which use wireless communication links to Error DU. 

communicate with link stations connected to the Internet. piG. 21 is a schematic diagram of the structure of LSROS 

Link stations provide browser proxy services to the tele- Acknowledgment PDU 

phone browsers. To push data to a browser, a WWW server ^2 is a schematic diagram of the structure of a Reply 

opens a TCP/IP connection to a link station, pushes data to Acknowledgment PDU. 

the link station, and closes the connection. The link station . . 

pushes the data to the phone browser over a connectionless f }^ » schematic diagram of (he structure of a 

protocol or a connection opened by the link station. If the Holdon FDU. 

link station uses a connection, the hnk station closes the FIG. 24 is a schematic diagram of the structure of a 

connection after transmitting the data. LSROS Failure PDU. 

The invention also provides a client simulator to help FIG. 25 is a schematic diagram of the structure of a 

developers to develop computer systems. In a client Cancel PDU. 

simulator, the link station functions arc performed by the FIG. 26 is a schematic diagram of a data network using 

client simulator SUGP protocol. 

In some embodiments, a client is a desktop computer or 45 FIG. 27 is a schematic diagram of the structure of a long 

some other stationary computer. In other embodiments, the header and a short header. 

client is a laptop, a notebook, or some other computer. pi^. 28 is a schematic diagram of a PDU body used in an 

A user is a human user and/or an application executed on SUG protocol. 

^ FIG. 29 is a schematic diagram of the sequence of events 
Other embodiments and variations are within the scope of 50 ^^^y^^^^ ^ browser and an UP.Link during the session 

the invention. The invention is defined by the appended creation process. 

FIG. 30 is a schematic diagram of a typical SUGP 

BRIEF DESCRIPTION OF THE DRAWINGS protocol at pwer on. 

i7f/- 1 • ui 1 J- f * 1 J- * *i. ss FIG. 31 is a schematic diagram of a normal request 

FIG. 1 IS a block diagram of a network accordmg to the -.u ■ *■ • 

, . ^ ^ process with an existing session, 

present invention. ^ * 

nc. 2 is a block diagram of a cache memory according ^, • k f ' ' 

to the present invention. established. 

no. 3 is a schematic diagram of a UGP operational FIG. 33 is a schematic diagram of a re-send process when 

^Qf^Ql oo the service credential is required. 

FIG. 4 is a schematic diagram of a simplified client FIG. 34 is a schematic diagram of a notification process, 

request process. FIG. 35 is a schematic diagram of the events of an error 

FIG. 5 is a schematic diagram of a typical client request scenario, 
process. 65 FIG, 36 is a schematic diagram of a cancellation scenario. 

no. 6 is a schematic diagram of a process for a client side FIG. 37 is a schematic diagram of the structure of an 

protocol state machine. SMM attachment. 
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DESCRIPTION OF PREFERRED 
EMBODIMENTS 

FIG, 1 illustrates a network 110 in which clients 120.1, 
120.2 can each perform both push and pull operations. Each 
client 120 has a cache memory 122 for caching both pushed ^ 
and pulled data. Client computer system 120.1 is shown in 
detail. System 120.2 is similar, and its details arc omitted for 
simplicity. 

In some embodiments, each system 120 is a handheld 
device, for example a cellular phone, a portable computer, or 
some other computer system. Each device 120 communi- 
cates with a link station 124. Each device 120 is connected 
to a wireless network 125 and the Internet. Link station 124 
is connected to the Internet. Gateway 126 connects the 
wireless network 125 to the Internet. In some embodiments, 
wireless network 125 is CDPD (Cellular Digital Packet 
Data), GSM, or some other network. CDPD is described, for 
example, in J. Agosta and T. Russell, "CDPD: Cellular 
Digital Packet Data Standards and Technology" (1997) 
incorporated herein by reference. See also R. A. Dayem, '^^ 
"Mobile Data & Wireless Lan Technologies" (1997) which 
described both CDPD and GSM and is incorporated herein 
by reference. In some CDPD embodiments, gateway 126 is 
MD-IS. 

In some embodiments, handheld devices 120 communi- 
cate with link station 124 over a connectionless protocol 
such as UGP (URLink Gateway Protocol), SUGP (Secure 
URLink Gateway Protocol, See Appendix A2) or HDTP 
(Handheld Device Transport Protocol). 

In some embodiments, different devices 120 communi- 
cate with different stations 124. 

Network 110 includes Wide-World Web (WWW) server 
stations 130.1, 130.2 connected to the Internet, and perhaps 
other such servers. Server 130.1 runs an electronic mail ^5 
service application 132. 

In some embodiments, one or more of devices 120 are 
connected to the Internet directly and not through gateway 
126. Further, in some embodiments, one or more devices 
120 are non-mobile systems. In some embodiments, devices 
120 and link station 124 arc combined in one entity used as 
a phone simulator. The entity is connected to the Internet. 
The phone simulator helps developers to develop the cellular 
telephones and link stations. 

Each device 120 includes a display (not shown) and a data 45 
entry device (not shown) such as a keyboard, a keypad, a 
mouse, or some other device. In addition, device 120 
includes a speaker capable to play audio hypermedia data. 
Each device 120 may include a computer processor (not 
shown). The computer processor can execute a browser 134 50 
(see Appendix Al for one embodiment of browser 134) 
which can display HDML files. HDML (Handheld Device 
Markup Language) is a hypermedia language which is a 
trimmed-down version of HTML (hypertext markup 
language). HDML is not a markup language, but is similar 55 
to HTML. HDML is suitable for systems having little 
memory.- 

HDML has two forms: a human readable ASCII textual 
form and a binary tokenized form. The binary tokenized 
form takes less space than the textual form. Tlius, the binary eo 
tokenized form is more suitable for those devices 120 which 
have little memory. The binary tokenized form is also 
suitable for high latency and/or low bandwidth networks 
such as CDPD. The binary tokens are defined in Appendix 
B. 65 

Browser 134 includes a cache management system (not 
shown) for managing cache 122. Some source code for the 
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cache management system is shown in Appendix E. Browser 
134 also includes an HDML engine (not shown) for receiv- 
ing hypermedia data from the cache (through the cache 
management system) or over a network and for displaying 
the video portion of the hypermedia data on the screen and 
for playing the audio portion of the hypermedia data over the 
speaker. In some embodiments, the browser cannot play 
audio data except possibly that the browser can make device 
120 beep. 

Appendix 1 describes push, pull, and other operations 
performed by a browser 134 executed by a device 120, for 
example, device 120.1. These operations are described on an 
example of a mail service 132. However, the invention is not 
limited to a browser or electronic mail. Further, device 120 
can perform the push, pull and caching operations on data 
received from multiple servers 130 running different ser- 
vices. For example, in some embodiments, some of the 
servers run applications providing stock reports, news 
messages, weather reports, or traOic reports to devices 120. 
Other server applications manage bookmarks for browser 
134 and other such browsers. All the data from mail service 
132 and the stock and bookmark applications and other 
services are cached in cache memory 122 as described 
below. 

Appendix 1 is self-explanatory, but we will clarify some 
steps now. 

Browser 134 executes an event loop. This means that the 
browser waits for an event to occur, and then processes the 
event. The pull operation includes steps BrA, BrB in Appen- 
dix 1. When a user of browser 134 requests data by selecting 
a URL, the browser 134 executes step BrA. Examples of 
user requests (pull requests) include, but arc not limited to, 
requests for a mail message or a header list of all messages 
in the user's mailbox. Browser 134 checks whether the data 
is in cache memory 122 (step BrAl). If the data is not in 
cache memory 122, browser 134 sends a pull request to 
browser proxy 150 (step Br A3). Proxy 150 is an application 
running on link station 124. The data pull path is shown at 
138. 

Pseudocode for browser proxy 150 is given in Appendix 
2. Proxy 150 translates the request into an HTTP GET 
request, and sends the HTTP GET request to mail service 
132 over the Internet using the TCP protocol (step Proxy2). 
When forming the GET request, the browser proxy 150 
inserts an HTTP request header which includes a user 
identification, for example, a telephone number of the cel- 
lular phone 120. 

HTTP version 1.1 allows browser proxy 150 to submit 
multiple requests over a single TCP connection. In some 
embodiments, browser proxy 150 sends multiple requests 
for the same or different users over a single TCP connection. 

Mail service 132 sends a response to browser proxy 150 
over the Internet. The response is an HDML file in the 
textual form. Communications between browser proxy 150 
and mail service 132 use the HTTP protocol on top of the 
TCP Internet protocol. 

Browser proxy 150 compiles the response into binarjf 
form (step Proxy4), and sends the response to browser 134 
over the Internet and the wireless network 125 (steps 
Proxy5-Proxy6). 

A server 130 can push data to browser 134 via messenger 
154. Messenger 154 is an application running on link station 
124. Pseudocodes for the messenger are shown in Appendix 
3, 

The data push path is shown at 156 in FIG. 1. When mail 
service 132 receives a new mail message for the user of the 
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device 1201, service 132 pushes two notifications to mes- 
senger 154 (steps NM2, NM3 in Appendix 4 which shows 
pseudocode for mail service 132). One notification includes 
at least a portion of the new message. The other notification 
includes at least a portion of a new header list. Each 
notification is pushed to messenger 154 over a separate 
TCP/IP connection. When the server sends the notification, 
the server closes the TCP connection. In some embodiments, 
the server sends both notifications over a single connection. 
In some embodiments, the new message (or a portion 
thereof) and the new header (or its portion) are sent as 
multiple data decks in a single notification. A format for 
sending multiple data decks in a single notification is 
described below. 

Some embodiments can send multiple notifications to 
different users over a single connection. An example is a 
stock quote service pushing the price of a selected stock 
when the price changes. Instead of opening and closing a 
separate connection for each user using the stock service, the 
server sends the notifications for multiple users over a single 
connection to messenger 154. 

In some embodiments, the notifications are sent via the 
HTTP protocol. In other embodiments, the notifications use 
a remote procedure call (RPQ protocol running on top of the 
TCP or UDP Internet protocols. In one embodiment, the 
RPC protocol is the Sun RPC also known as ONC (Open 
Network Computing). This protocol was developed by Sun 
Microsystems, Inc. of Mountain View, Calif. 

If needed, messenger 154 compiles the HDML data in the 
notification into the binary form (step M2 in Appendix 3). 
ITien messenger 154 sends the notification to browser 134 
(step M4). 

Browser 134 caches the data contained in the notification 
(step BrB6). If cache 122 contains an earlier version of the 
data (for example, a previous header list), the earlier version 
is deleted. 

FIG. 2 illustrates cache memory 122. The memory con- 
tains a number of entries 210.1, 210.2, etc. Only entry 210.1 
is shown in detail. In addition to data deck 214 (data 
contents), the entry contains DECKID 218, DECKSEQ 222, 
and time-to-live 228. Some embodiments include additional 
fields, for example, a data type. 

Deck ID 218 is a globally unique identifier of the deck. In 
some embodiments, deck ID 218 is a URL. An example is 

http://www.mail.com/cgi-bin/mail.exe7h for a header list, 

or 

http://www.mail.com/cgi-bin/mail.exe7msgidH32 for a 
mail message. 

In some embodiments, mail service 132 breaks messages 
into blocks of 200-400 bytes. Each block is made a separate 
deck. The deck is assigned a URL which includes the 
message URL and the oliiset of the block from the beginning 
of the message. An example of a deck ID for a message 
block at ofiEset 200 is 

http://www.mail.com/mail.exe? msgid=32&offset=200. 

If the deck is not the last deck of the message, the deck 
is terminated with a hypertext link "more" associated with 
the URL of the next deck of the message. 

Similarly, a header list is broken into decks of at most 10 
lines each. Each block is a separate deck. If a header 
includes more than one deck, each deck (except possibly the 
first one) is identified by an offset parameter in the URL. 
Each deck except the last one is terminated with a "more" 
link to the next deck. 

Deck sequence, or version, 222 is a sequence number 
allowing browser 134 to determine which version of the data 
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is more recent. The browser may receive the same kind of 
data (for example, the header list) through the pull request 
to browser proxy 150 and through the push from messenger 
154. A more recent version of the data may arrive before a 
5 less recent version. The browser uses the deck sequence 222 
to discard the less recent version. See step BrB4 in Appendix 
1. 

In some embodiments, the sequence number is assigned 
by the WWW service (such as mail service 132). In other 
10 embodiments, the sequence number is assigned by link 
station 124 as described in more detail below. 

Time-to-live (TTL) 228 is specified by the WWW service 
(for example, mail service 132). TTL is specified in seconds 
or some other dme units. If the time-to-live has expired, the 
browser will not use the cached deck but will pull the data 
from the server. 

In some embodiments, a special TTL value is reserved for 
an infinite time-to-live. In some embodiments, TTL 228 is 
16 bits long, and the special TTL value for the infinite 
time-to-live is hexadecimal FFFF. 

The browser maintains a global state indicating the cur- 
rent deck being processed. 

When browser 134 detects a network event indicating the 
25 receipt of the RequestReply PDU from proxy 150, browser 
134 executes the step BrB (Appendix 1). 

The sub-steps BrBl-BrB7 of step BrB are executed for 
each deck in the PDU. If the user is pulling a message or a 
header list, the PDU will contain only one deck. If the user 
30 is pulling all his new mail, the PDU will contain two deck 
in some embodiments. The first deck is a header list (or a 
block of the first ten lines of the header list). The second 
deck is one of the new messages (or a portion of a new 
message). 

At step BrB3, browser 134 determines the URL of the 
deck. In some cases, the deck's URL is the URL that was 
sent by the browser at step Br A3 with the pull request. This 
is the case, for example, when the pull request was generated 
in response to the user selecting a URL of a header list or a 
message from a header list, or clicking on "more" at the end 
of a deck representing a portion of a message or a header list. 

In some cases, an entirely new URL is assigned to the 
deck at step BrB3. One such case is when the user selected 
a URL associated with new mail. As stated above, service 
132 returns two decks. The header list deck has the URL of 
the header (or a portion of the header). The message deck 
has the URL of a message (or a portion of a message). These 
URLs are attached to the respective deck by mail service 

50 

At step BrB4, the browser determines if the deck should 
be ignored due to its sequence number DECKSEQ. A 
separate sequence number is generated by mail service 132 
for each user mailbox. For each mailbox, mail service 132 
55 increments the sequence number whenever the set of mes- 
sages in the mailbox changes, for example, when a message 
is received or deleted (see, for example, step NMl in 
Appendix 4). If mail service 132 did not specify any 
sequence number for the deck, Uie deck is not ignored by 
browser 134 (step BrB4-l), i.e. the deck will be used by the 
browser. 

At step BrB4-3, deck sequence numbers are compared as 
shown in the C programming language code of Appendix D. 
More particularly, the old deck's sequence number is sub- 
65 tracted from the new deck's sequence number. 

Each sequence number is a 16-bit unsigned integer. To 
accommodate wrap-around, the difference of the sequence 
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numbers is treated as a two's complement signed 16-bit 
integer. If this integer is positive, the old deck is considered 
older than the new deck. If this integer is negative, the new 
deck is considered older. If the integer is 0, the sequence 
numbers of the two decks coincide. 

Notifications are handled as follows. When messenger 
154 receives a notification from a server 130, the messenger 
queues the notification in a queue allocated for the destina- 
tion device 120 (step M3 in Appendix 3). A separate queue 
is kept for each browser 134. If the notification includes 
HDML data, the messenger compiles the data into binary 
form (step M2). Of the two notification types described 
below, the DataPush includes HDML data, and the InvalSer- 
vice (invalidate service) does not. 

If the queue for browser 134 is not empty, the messenger 
periodically tries to contact the browser When the browser 
is contacted, the messenger sends all the notifications in the 
queue to the device over UGP or HDTP. 

One embodiment of notification type data structures and 
other data formats and programmatic interfaces used by 
browser 134 and link station 124 to communicate via UGP 
is described in the C programming language header file 
reproduced in Appendix C. 

A DataPush notification entry in a messenger queue (after 
compiling of the HDML data) has the following form: 

1) One byte includes the number of URL/TIL pairs in the 
entry. TIL is a binary tokenized HDML deck identified by 
the URL. 

2) One byte includes flags. Rags indicate "side -effects" 
the browser should perform on receipt of the data. The "side 
effects" may include causing the device 120 to beep, to play 
a tone, to vibrate, to flash a light, etc. In another 
embodiment, the flags are replaced by an alert entity which 
contains a one-line textual description of the activity that 
caused he "side effect". 

3) For each URL/TIL pair, the entry has the following 
fields: 

3A) A variable length field includes the URL string (null 
terminated). 

3B) Two bytes indicate the length of the TIL data deck. 

3C) A variable length field contains the TIL data deck. 

In addition, for each URL/TIL pair the notification may 
include a sequence number DECKSEQ and a time-to-live. 

When the browser receives a DataPush notification, the 
browser performs the step BrC (Appendix 1). 

Step BrCachelnsertion in Appendix 1 is a routine invoked 
to insert a new deck into the cache. This routine is invoked, 
for example, at steps BrB6, BrC4. 

The InvalService (invalidate service) notification is sent 
by a server 130 to invalidate one or more cache entries. In 
response, browser 134 performs step BrD (Appendix 1). 
One form of the invalidate service notification is "invalidate- 
specific-ID". This notification includes a single URL. The 
browser 134 invalidates the cache entry having this URL. 
Another form of the invalidate service notification is 
"invalidate-matching-ids." In this form, only a portion of the 
URL is specified, for example, the beginning (prefix) por- 
tion. In response, browser 134 invalidates any cached entries 
with URLs having a matching portion. 

In some mail applications, invalidate service 
(InvalService) notifications are issued by mail service 132 
when the mail server receives a new message for a user of 
a device 120. Before pushing the new header list, the mail 
service pxishes an invalidate service notification to invalidate 
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any cached portions of the header fist. Further, in some 
embodiments, the mail service invalidates the cached header 
list entries but does not push the new header list. When the 
user requests a header Ust, the browser will pull the header 
5 list from the mail service 132 because the header list entries 
previously cached have been invalidated. In some 
embodiments, the header list is not pushed because the push 
path 156 goes over a more expensive network than the pull 
path 138. In other embodiments, header lists are not pushed 
to reduce the amount of data transmitted. The amount of data 
is reduced because the user gets the header list only when the 
user wishes to see it. 

In another embodiment, browser 134 allows the user to 
specify preferences including, for example, a particular time 
zone. The dates and times in the mail messages are refer- 
enced to the time zone specified by the user. If the user 
changes the time zone (because, for example, the user moves 
to a different time zone), server 132 is notified by link station 
124. When mail service 132 learas of the time zone change, 
mail service 132 pushes an invalidate -service notification to 
invalidate all the mail messages in cache memory 122. (Of 
note, cache memory 122 may include other data besides the 
mail messages. The other data may be supplied by other 
services.) Hence, cache 122 will be rid of the mail messages 
that include the dates and times referenced to a previous time 
zone. 

In another embodiment, browser 134 caches a bookmark 
list in cache memory 122. A bookmark application runs on 
a server 130 and services the requests to edit the bookmark 
list. If the user edits the bookmark list, the browser informs 
the bookmark application, and the bookmark application 
pushes an invalidate service notification to invalidate all the 
bookmarks in cache memory 122. 

In some embodiments, messenger 154 assigns a time-to- 
live parameter MTTL (messenger time-to-live) to each noti- 
fication received by the messenger. The MTTL may be 
different from the time-to-live assigned by servers 130 and 
used for cache 122. If a notification has been in a messenger 
queue longer than MTll^ and the messenger has not been 
able to send the notification to the respective browser 134, 
the messenger deletes the notification from the messenger 
queue. Thus, if multiple header lists have been pushed by 
service 132 while the user device 120 was off, the header 
fists not delivered by the messenger for time MTTL will be 
deleted. The probability that outdated header lists will be 
pushed to device 120 will therefore be reduced. 

In some embodiments, a server 130 may push a command 
to messenger 154 to delete one or more notifications from 
the messenger queues if the notifications have not been 
50 delivered to the browsers. 

In some embodiments, for each data push notification, the 
messenger 154 deletes any undelivered notifications that 
have the same URL and are destined for the same browser 
134. 

55 In some embodiments, a stock application on a server 130 
sends stock prices to devices 120. A user may request the 
stock application (via the pull path 138) to push the price of 
a given stock when the price gets above or below a certain 
value. Alternatively, the user may request the application 

60 (via the pull path) to push the price at regular intervals of 
time, for example, every hour. In some embodiments, the 
stock application pushes the stock price via the SMS when- 
ever the stock price changes. SMS stands for Short Message 
Service. This service is inexpensive or free in some net- 

65 works. 

In some embodiments, browser 134, messenger 154, 
browser proxy 150, and mail service 132 are products of 
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Unwired Planet, Inc. of Redwood Shores, Calif. Devices 120 
are model MA210 cellular phones available from Mitsubishi 
or model Duette cellular phones available from Samsung. 
Browser 134 is stored in the ROM of devices 120. The 
browser size is 60-130 KBytes. 

The cellular phone also has 20-26 Kbytes of RAM of 
which about 14-20 Kbytes are used for cache 122. The 
RAM is non-volatile due to a built-in battery power source. 

In some embodiments, the sequence numbers 
(DECKSEQ) are generated not by servers 130 but by link 
stations 124. A separate sequence number is kept for each 
browser 134. Station 124 increments the sequence number 
for each deck received for browser 134 by proxy 150 or 
messenger 154, and attaches the sequence number to the 
deck. Browser 134 discards any data, whether pushed or 
pulled, that have a lower sequence number than any data 
previously received by the browser even if the previously 
received data have a different URL. 

The advantage of this approach is removing the need for 
each server application (for example, mail service 132) to 
maintain deck sequence numbers. The disadvantage is that 
the browser 134 may unnecessarily discard pushed data. For 
example, suppose email server 132 pushes a new message, 
and the message is given a sequence number 100 by the link 
station. Then the user pulls a stock quote from another 
service, and the stock quote gets sequence number 101. If 
the browser receives the stock quote before the email 
message, the browser will discard the email message. 
However, this disadvantage is minimized if the data push 
path 156 has low latency. Indeed, if the latency is low, the 
probability is small that pushed data having a lower 
sequence number than pulled data is received by browser 
134 after the pulled data. 

Further, in some such embodiments, the servers 130 do 
not push any DataPush notifications to the browsers. Instead, 
the servers 130 push only the URL of new data to messenger 
154. The messenger queues the URL but does not push the 
URL to the browser. Instead, the messenger pushes to the 
browser a notification that a new URL has been received. 
Then browser 134 issues a pull request to browser proxy 
150. Browser proxy 150 gets the new URL from the mes- 
senger and issues an HTTP GET request to a CGI program 
identified by the URL. The data returns to the browser via 
the pull path 138. One such embodiment is described in 
Appendices 5 and 6 which refer to this embodiment as 
version 2.0. 

Such embodiments are suitable for GSM networks having 
an inexpensive SMS service. Indeed, since the notifications 
are short, they can be sent inexpensively via the SMS. (Data 
pull operations can use more expensive GSM links suitable 
for transfer of long messages.) 

Balancing the latency and the cost of data access is an 
important issue confronting users of wireless networks. Id 
some embodiments, the user is given explicit control over a 
caching strategy that determines when data should be pulled 
or pushed. Thus, the user is enabled to optimize the cost/ 
latency tradeoff on a network by network, device by device, 
or user by user basis. 

For example, if latency is high but data transport cost is 
low, the user may choose to have more data to be pushed to 
the user. Conversely, if the latency is low but the data 
transfer cost is high, the user may choose to pull more or all 
of the data. 

Thus, in some embodiments, the user may request mail 
service 132 not to push any data. Alternatively, the user may 
request mail service 132 to push only invalidate notifica- 



tions. Alternatively, the user may request mail service 132 to 
push data not more often than a given time interval. 
Alternatively, the user may request the mail service to push 
new mail notifications only when a predetermined minimum 

5 number of new messages has been received in the user 
mailbox, and to push invalidate service notifications accord- 
ing to some other poUcy. This is not an exhaustive list of how 
the user may control the push operation to optimize for the 
cost and latency parameters. The user issues such requests 

10 via the pull path 138. 

In some embodiments, network 125 is a GSM network, 
and notifications from messenger 154 to browser 134 travel 
over SMS. Because the push notifications are inexpensive, 
the user may prefer to have more data pushed to the device 

15 120. 

Appendix F lists the source code of one embodiment of a 
browser and a link station according to the present invention. 
Appendix G lists the source code of one embodiment of a 
mail service of the present invention. 

The above embodiments illustrate but do not limit the 
invention. In particular, the invention is not limited to the 
Internet, the WWW, or to browsers. In some embodiments, 
cache 122 is managed by a non-browser application. Cache 
memory 122 may include semiconductor and/or non- 
semiconductor memories, e.g. a disk, or any other computer 
store. The invention is not limited to a particular type or 
capabilities of devices 120. Some devices 120 include a 
speaker, others do not. Other embodiments and variations 
are within the scope of the invention, as defined by the 
appended claims. 

APPENDIX 1 

BROWSER OPERATION 
The browser executes an event loop waiting for an event. 

Pull Operations 
BrA, Input event indicates the selection of a URL. 

BrAl. The cache is searched for an entry 210 (FIG. 2) 
with a matching URL. 
40 BrA2. If a matching entry is found, the respective deck 
214 is made the current deck and is displayed by the 
browser. The browser returns to the top of the event loop to 
wait for the next event. 

BrA3. Otherwise (no matching URL is found), the 
45 browser sends a request PDU (packet data unit) containing 
the selected URL via HDTP. 

BrB, A network event indicates the receipt of the Reques- 
tReply PDU. This is a reply to the pull. The browser sends 
an Acknowledge PDU to the browser proxy 150. For each 
50 deck in the PDU, the browser performs the following: 

BrBl. Copy the URL and HDML contents out of the 
notification PDU, 

BrB2. Check the HDML contents for validity (i.e. that 
there is no corruption, and that the PDU format is a 
55 supported version). 

BrB3. Determine a URL for the deck. 

BrB4, Determine if the deck should be ignored due to its 
sequence nmnbcr: 

BrB4-l . If no sequence number is specified for the deck 
60 by the server (e.g. by mail service 132), the deck is not 
ignored (i.e. it will be used). 

BrB4-2. If a sequence number is specified for the deck, 
cache 122 is searched for an entry with a URL that matches 
the deck's URL (this deck is called a "new" deck or a "newly 
65 received" deck below). If there is no such entry, or the entry 
does not have a sequence number 222, the newly received 
deck is not ignored. 
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BrB4-3. If cache 122 tias an entry with a matching URL, 
and if both this entry and the new deck have sequence 
numbers, the sequence numbers are compared. If the "old" 
deck (the deck in the cache entry) is newer than the newly 
received deck, the newly received deck will be ignored. 5 
Otherwise, the newly received deck is not ignored. 

BrB5. If the newly received deck is to be ignored, then 
SearchForCacheEntry Q is called to get the old deck. This 
procedure returns a pointer to the HL data (binary tokenized 
HDML data) so that the old deck can be displayed. ao 

BrB6. Otherwise, if the newly -received deck's time-to- 
live is not specified by mail service 132, or Ls specified and 
is not 0, the newly received deck is inserted into the cache, 
and any old cache entries with matching URLs are deleted. 
If the new deck's time-to-live is zero, the new deck is not 15 
cached. However, if an old deck exists with a matching 
URL, the old deck is deleted. 

BrB7. If the new deck's TTL is not 0, the deck in the 
cache entry is made the current deck, and is displayed by the 
browser. If the new deck's TTL is 0 and the new deck is not 20 
ignored, the new deck is displayed by the browser. Then the 
browser returns to the top of the event loop. 

Push Operations 
BrC. An event indicates the arrival of a DataPush notifica- 
tion. For each URL/TIL pair in the notification, the browser 
performs the following: 

BrCl. Copy the URL and HDML contents out of the 
notification PDU. 

BrC2. Check the contents for validity (no corruption, 
supported version; similar to step BrBl). 

BrC3. Determine if the deck should be ignored due to its 
sequence number (as in step BrB4). 

If so, ignore it and move on to the next deck in the entry 
or the next entry in the PDU (go to step BrCl), or to the top 
of the event loop if this is the last deck. 

BrC4. The deck is not to be ignored. If its time-to-live is 
specified and is not 0, then insert the deck into cache 122, 
replacing any cache entries with a matching URL (as in step 
BrB5). 

BrC5. If the deck has the same URL as the cunently 
displayed deck, the deck is made the current deck and is 
displayed. 

BrD. An event indicates the arrival of an invafidate-service 
notification. 

For each entry in the cache, if the entry's URL matches 
any URL in the invalidate service notification, the cache 
entry is deleted from the cache. 

Other Browser Operations 
BrE: Update time-to-live in cache 122. An event indicates 50 
expiration of a predetermined time interval ("expiration 
interval") since the last updating of the time-to -live param- 
eters in the cache. A cache expiration routine is invoked 
which performs the following. For each entry in the cache, 
if the entry's time-to-live is less than the expiration interval, 55 
the entry is deleted. Otherwise, if the entry's TTL is not 
FFFF (infinity), the TTL is decremented by the expiration 
interval. In some embodiments, the FFFF values are also 
decremented by the expiration interval, i.e. infinite TTLs are 
not allowed. 60 
BrCachelnsertion. If there is not enough free space in the 
cache for the new entry, a least recently used (LRU) entry is 
deleted from the cache. If the new entry still does not fit, 
another LRU entry is deleted. This continues until enough 
room is freed in the cache to accommodate the new entry. 65 
The maximum deck size is selected such that the maximum 
size of any new entry is smaller than the size of the cache. 
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If time-to-live has not been specified, the time -to-live 228 
(FIG. 2) is set to a default value (3 days in some 
embodiments). 

APPENDIX 2 

BROWSER PROXY 

Browser proxy 150 provides a UGP to HTTP protocol 
gateway as follows: 

Proxy 1. Receive a Request PDU from a browser 134. 
Proxy2. Submit an HTTP GET request to a WWW server 

130 (e.g., mail service 132). 
Proxy3. Receive an HTTP response (textual HDML file) 

from the server. 
Proxy4. Compile the response into binary tokenized form 

and/or compress the response. 
ProxyS. Send the binary tokenized HDML file to the browser 

in a RequestReply PDU. 
Proxy6. Receive an Acknowledge PDU from the browser. 

APPENDIX 3 

MESSENGER 

The messenger provides an RPC interface for server 
appUcations for notification submission and processing: 
Ml. Receive a notification from an application running on a 

server 130 via the Messenger RPC interface. 
M2. If the notification includes an HDML file, compile the 

file into binary form. 
M3. Queue the notification (with binary-form HDML file, if 

any) in a queue of notifications for a particular browser. 
M4. Check periodically if the browser is connected to the 

wireless network. If the browser is connected, send the 

notifications to the browser via UGP or HDTP. 

APPENDIX 4 

MAIL SERVICE 132 

The mail service services pull requests and performs data 
pushes. 

If a new mail message is received, perform the following 
operations: 

NMl. Insert the new message into the user's mailbox, and 

increment the user's deck sequence number. 
NM2. Generate a DataPush notification including an HDML 
deck containing the new message (or a portion of the new 
message if the message is too large), and send the 
notification to messenger 154. 
NM3. Generate a DataPush notification including an HDML 
deck with a new header list (or first 10 lines of the header 
list) and send the notification to messenger 154. 
The deck sequence numbers solve the problem presented 
by another message arriving and the user pulling the new 
header list before the previously submitted data push noti- 
fication arrives at browser 154. 

APPENDIX 5 
UP.Link Digest Format 
Introduction 

The UP.Link Digest is a multipart message sent to an 
UP.Browser (i.e. browser 134). The scenario for the creation 
of a digest is the HTIT service (e.g. mail service 132) replies 
to a GET with "multipart/mixed" content-type. The UP.Link 
(i.e. link station 124) converts the multipart/mixed content 
into a binary format understood by the UP.Browser. 
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This Appendix specifies: 

Content types and their conversions 

Hie HTTP Response headers used to create URLink 
Digests 

The binary digest format 5 
Digest Overview 

An URLink digest contains zero or more typed digest entry. 
Each entry type has an associated HTTP content-type, and 
binary digest entry type. 

The order in which digest entries are specified Ls significant. 

When converting from HTTP to binary format, the order will 

be preserved. The UP.Browser will interpret each entry in 

the order presented. 

Content Types and their Conversions 

A content type can be recognized by the URLink and 

converted into another content type or subtype. For example, 

the URLink compiles HDML source into HDMLC 

(compiled, i.e. binary tokenized, HDML). It might also 

convert images into a format usable by the UP.Browser. 
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Entity Headers 

The entity headers of interest in the entities of a multipart/ 

mixed message are: 

Content-Length 

The content-length is not required, however there is a 
significant performance improvement if it is used. 
Content-Location 

If the Content-Location is a relative URI, the URI is 
interpreted relative to any Content- Base URI provided in the 
response. If no Content-Base is provided, the relative URL 
is interpreted relative to the Request-URI. 
Content-TVpe 

The content-types of individual entities are summarized in 
the table above. 

Entity Content lype Parameters 

Some of the entity content types used in URLink digests 
take parameters as summarized in the table below 
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Digest 





HTTP/MIME 




Entry 


Content 


Media T^'pe 


Conversion 


Type 


Alert 


application/x-up- 
alert 
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Cache 


application/x-up- 


Operation 
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Operation 


cacheop 
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HDML 


lexl/x-hdml 


HDML Compiler 
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Images 


image/" 
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convert image 
formats 
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Device 
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Data 
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Unknown 


application/x-up- 


none 


6-254 


Digest 


digestentry 
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Unknown 


V* 


none 
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HTTP Headers 

HTTP/LO [RFC1945] and HTTP/l.l [RFC2068] differ 
somewhat in their definition and usage of response headers. 
Particularly with regard to multi-part messages, lliis speci- 
fication attempts to span both versions of the protocol by 
using the headers defined in HTTP/l.l and supporting 
backwards compatibilty with H lTV/1.0 headers where they 
overlap with HTTP/l.l. 
Response Headers 

The entity headers of interest in the response header are: 
Content-Base 

The Content-Base entity-header field may be used to 
specify the base URI (Uniform Resource Identifier) for 
resolving relative URIs within the entity. If no Content-Base 
field is present, its Content-Location (if that Content- 
Location URI is an absolute URI) or the URI used to initiate 
the request, in that order of precedence. 
Content-Encoding 

The URLink will not handle any content encoding for 
Magellan. Content encoding will result in an error. 
Content-Type 

The content- type of the response must be one of 

text/x-hdml 

apphcation/x-hdmlc 

multipart/mixed 

All other content-types in the response header will gen- 
erate an error. 



Entity 
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Content 


Para- 




type 


meter 


Description 


application/ 


type 


The digest entry type of the 


x-up- 




contents. This is an unsigned 


digestentry 




integer <= 255. Example: 






applies tion/x-up-digestcn try; 






type««6 


application/ 


name 


The name of the device data. 


x-up- 




Example; 


device 




application/x-up- device ; 






name«addibookl 



Binary Digest Format 

The purpose of the binary digest is to combine multiple 
items of binary data in as compact a form as possible. The 
format explicitly gives no consideration to byte alignment 
and is not padded. In the following description, a variant of 
the C structure syntax is used, char is a one-byte integer, 
short is a two -byte integer, and long is a four-byte integer. 
Multi-byte integers are big-endian, i.e. the bytes appear in 
the following order on-the-wire: <MSB> , . . <LSB>. The 
base URL is assumed to be known, a priori, by the browser. 
In the case of an interactive request, it is the requested URL. 
Otherwise, the base URL is assumed to be relumed by the 
lower-level protocol. 
The overall format is as follows: 

50 ' 

struct digest { 

struct digest^hdr header; 
unsigned char entries { J 

): 



The format of the header is as follows: 



(50 struct digest_hdr { 

unsigned char magic; /• DIOEST_MAG[C — Oxcf */ 

unsigned char nEntries; 

} 



65 NEntries specifies the number of entries to follow. The 
maximum number of entries in one digest is 255. The 
generic format of an entry is as follows: 
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struct digcst_cntry { 
unsigned char 
unsigned short 
unsigned char 

} 



type; 

contcntLcngth; 
contents [ ]; 
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url+strlen(url)+l 
The length of the deck can be calculated as 

entry.coDtentLength-strlen(url)-l 
Image 

The format of the Image entry is as follows: 



Type specifies the type of the entry (see below). Con- 
tentLength indicates the length of contents. The subsequent lo 
entry follows directly after contents. The following entry 
types are supported: 



struct imagc_entry { 
struct digest_cntry 
unsigned chai 
cbar 

unsigned char 

} 



entry; 

imageType; 
urllt 
data[ ]; 



Null 


0x00 


Alert 


0x01 


Qiche Operation 


0x02 


HDMLC Deck 


0x03 


Image 


0x04 


DeviceData 


0x05 


Unassigned 


0x06-0xfe 


Unknown 


Oxfif 



NuU 

The Null entry has no useful data, its contents will be 

ignored. 

Alert 

The Alert entry uses the generic entry format. The contents 
of an alert entry in the binary digest is as follows: 

typc\0title\Ourl\O 
Cache Operation 

The format of the Cache Operation entry is as follows: 



15 The image types are TBD. 

Url is a NULL(OxOO) terminated URL relative to the base 
URL. The image data immediately follows the terminating 
NULL byte. The start of the data can be calculated as 
url+slrlen(url)+l 
20 The length of the image data can be calculated as 
entry.contentLength-strlen(url)-2 
Device Data 

The format of the DeviceData entry is as follows: 
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struct cachcop_entry { 
struct digest_entry 
unsigned char 
char 

} 



entry; 
opcode; 
operand[ ]; 



Opcode should be one of the following: 



struct dcvicc_entry { 
struct digest_entry 
char 

unsigned char 

} 



entry; 
namcf ]; 
data[ ]; 



Name is the null(OxOO) terminated name of the data. The 
data immediately follows the terminating null byte. The start 
of the data can be calculated as: 
35 name+strlen(name)+l 

The length of the data can be calculated as 

entry.contentLength-strlen(name)-l 
Unknown 

The unknown entry type is the back door for forward 
40 compatibility. The fonnat of the unknown entry type is as 
follows: 



Reserved 0x00 

Invalidate- Service 0x01 

Invalidate-URL 0x02 

Unassigned 0x03-0xff 



The operand the InvaUdate-Service opcode is a NULL 
(0x00) tenminated URL prefix. All cache entries which 
prefix match the operand will be invalidated. The operand 
for the Invalidate-URL opcode is a NULL (0x00) terminated 
URL to invalidate. These URLs are relative to the base URL 
of the response. 
HDMLC Decks 

The format of the HDMLC deck entries is as follows: 



struct deck:_entry { 

struct digest_entry entry; 
char url[ ]; 

unsigned char deck( ]; 

} 



Url is a NULL(OxOO) terminated URL relative to the base 
URL. The contents of the deck immediately follow the 
terminating NULL byte. The start of the deck can be 
calculated as: 



45 



struct unknown_entry { 




struct dige5t__entry 


entry; 


char 


urlll 


char 


mimciype [ ]; 


unsigned char 

} 


data[ ]; 



50 

Url is the null (0x00) terminated name of the entry data 
relative to the base URL. MimeType starts immediately after 
this null byte and is null-terminated ASCII MIME type of 
the entry. Data starts immediately after this second null byte 
55 and is the contents of the entry. The start of mimeType can 
be calculated as: 

url+strlen(url)+l 
The start of the data can be calculated as: 

url+strlcn(url)+strlen(mimcType)+2 
60 The length of the data can be calculated as: 

entry.cantentLength-strlen(name)-strlen(mimeType)-2 
Content-Specific Handling 
Alerts 

The body of the alert entity should be in the following 
65 format; 
type\n 
title\nuri\n 
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Cache Operations 

The body of the cache operation entity contains a www-url- 
encoded list of key-value pairs. The following keys and 
values are recognized: Well-known keys and values are 
case-insensitive. 



Key Value Description 



Opcode Invalidate 


Invalidate the cache entry that 


URL 


matches the URL in the Content- 




Location entity header 


Invalidate 


Invalidate all cache entries that 


Svc 


prefix match the URL in the Content- 




Location entity header 



HDMLC Decks 

If an uncompiled HDML deck (text/x-hdml) is presented to 
the UP.Link, it will be compiled into HDMLC and then 
inserted into the binary digest. 
Security Considerations 
Relative URLs 

Some of the security mechanisms in browser are based on 
the accuracy of the URLs of cache entries. To prevent one 
service from spoofing another, all URLs in digest entries 
must be relative to the base URL of the digest. 

APPENDIX 6 
UP.Browser 2.0 Content-Types 
Introduction 

The 2.0 Version of the UP.Browser (browser 134) is capable 
of processing a limited number of content types. Depending 
whether the UP.Browser communicates with the web server 
via an UP.Link proxy (browser proxy 150) or not, it expects 
the content in cither the MIME [RFC152i] message format 
or a binary encoded format. The UP.Link proxy converts 
from MIME message format to binary encoded format. 
This Appendix specifies the MIME message format of the 
UP.Browser 2.0 content types. 
Overview 

In MIME format, browser content can be single message 
entities or a combined, "multipart/mixed", message entity. 
The latter is referred to as a Digest. The order in which 
digest entries are speci&ed is significant. When converting 
from HTTP to binary format, the order wUl be preserved. 
The UP.Browser will interpret each entry in the order 
presented. The following content types have been defined 
for URBrowser 2.0: 





HTTP/MIME 


Content 


Media Type 


Alert 


application/x-up-alert 


Cache Operation 


application/x-up-cacheop 


HDML 


tcxt/x-hdml 


HDMLC 


application/x-hdmlc 


Device Data 


applicatio n/x-up-device 



NOTE: It is expected an image content type wilt be defined. 



HTTP Headers 

HTTP/LO [RFC1945] and HTTP/1.1 [RFC2068] differ 
somewhat in their definition and usage of response headers, 
particularly with regard to multi-part messages. This speci- 
fication uses the headers defined in HTTP/1.1, 
For security reasons, some headers are interpreted in a 
restricted manner, as summarized below. 
Response Headers 

The restricted entity headers in the response header are: 
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Content- Base 

The Content-Base entity header field is ignored by the 
UP.Browser and UP.Link in 2.0. 
Content-Encoding 
5 The UP.Browser and UP.Link will only handle the fol- 
lowing content encodings in 2.0: 

Tbit 

8bit 

binary 
30 Content-Type 

The content-type of the response must be one of the 
content types listed in the "Accept" request header or 
"multipart/mixed". If "multipart/mixed", all of the parts of 
the multipart message must be listed in the "Accept" header. 
IS All other content-types in the response will generate an 
error. 

Certain UP.Browser implementations may accept content 
types beyond those described in this document. If so, those 
additional content types will be listed in the "Accept" 
20 request header. 
Content-Length 

The content-length is not required, however there may be 
a significant performance improvement if it is used. 
Entity Headers 

25 The entity headers of interest in the entities of a multipart/ 
mixed message are: 
Content-Location 

For security reasons, Content-Location headers must con- 
tain relative URLs. In 2.0, the UP.Browser and UP.Link 
30 wOl only accept content with a URI that contains the 
same net_loc as the requested URI. If your application 
needs to return content from a different network 
location, HTTP redirection should be used. 

Content-T^pe 

35 The content-type of the entity must be one of the content 
types listed in the "Accept" request header. All other 
content-types in the response will generate an error. 
UP.Browser Content Types 

Specifications for the individual content types follow. 
Alert (application/x-up-alert) 

The alert content type embodies an indication to the user that 
an asynchronous event has occurred. Typically, an alert will 
cause the phone to beep. For example, an alert can be sent 
to the browser as a result of new mail arriving in an urgent 
inbox or a stock value reaching certain level. 

The application/x-up-alert content type is formatted the 
same way as application/x-www — ^form-urlencoded. The 
contents of the alert are parameterized into a URL query 
string with the values escaped as appropriate. The alert 
50 consists of the following parameters: 



55 



Type 


The alert type specifies how the browser should 




signal the user that the alert has arrived. 


Title 


The title of the aleit as displayed in the 




UP. Browser's alert inbox. 


URL 


The URL to display when the mer selects the 




alert The UP.Browser coalesces alerts based on 




the URL. If you submit a new alert with a 




dififerent title but the same URL, it will 




overwrite any old alerts with the same URL, This 




allows you to have an entry in the alert inbox 




whose title contains current, updated 




information such as a stock price. 



65 Example 

The following alert: 
Type: D — 
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Title: New Mail URL: /?S»HP 
Would be encoded as follows: 

Content-Type: application/x -up -alert 

Type=D— &Titl6=New+Mail&URL=%2F%3FS%3DHP 
Cache Operation ( application/x -up-cacheop) ^ 
The cache operation content type embodies a command to 
the UP.Browser to manipulate the cache. Typically, an 
application will use this to invalidate stale data that may still 
be residing in the browser's cache. 
The application/x -up-cacheop content type is formatted the 
same way as application/x -www-form-urlencoded. The con- 
tents of the cache operation arc parameterized into a URL 
query string with the values escaped as appropriate. The 
cache operation consists of the following parameters: 
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OpCodc 




Hie operation to pcrfonn. 




Operand 




The operand of the operation. 




The following 


Opcodes 


are supported: 


20 


OpCode 


operand 


Description 




Invalidate 


URL 


This operation invalidates the entry 


25 


URL 




in the cache with the matching URL. 








It mvsl be an exact match 




Invalidate 


URl^ 


This operation invalidates any 




Svc 


prefix 


entries in the cache that match the 






operand. A simple string prefix match 








is done. If the URL of the cache 


30 






entry prefix matches the operand, the 






entry is removed from the cache. 
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Example 

The following cache operation: 

InvalidateURL: http://up.foo.com/tcst.cgi?S=42 
Would be encoded as follows: 

Content-Type: application/x -up-cacheop 
OpCode=InvalidateURL&Operand« 
httpt%3A%2F%2Fup.foo,com%2Ftest.cgi 53FS%3D42 
Handheld Device Markup Language (text/x-hdml and 
application/x-hdmlc) 
Handheld Device Markup Language comes in two forms, 
textual source code (HDML) and compiled binary 
(HDMLC). When sending HDML to the UP.Browser, use 
the "text/x-hdml*' content type. When sending HDMLC, use ^5 
"application/x-hdmlc". The bodies of the message entities 
are the HDML and HDMLC respectively. 
Example 

The following is an example of HDML content. 

Content-iype: text/x-hdml 50 

<HDML version-2.0> 

<DISPLAY> 

Hi, Mom! 

</DISPLAY> 

</HDML> 
Device Data (application/x-up-device) 
The device data content type encapsulates data to be passed 
to an internal device-dependent application. It is primarily 
used as a mechanism to transport opaque data from a web 
server to a built-in device application. The data is given a 
device-dependent name which is used by the device to 
determine its internal destination and content type. 

The "application/x-up-device** content header has an 
additional parameter, "name**, which is used to specify the 
name of the data. For example: 

The body of the device data message entity is the data itself. 65 
The fonnat of the data is totally device-dependent and is 
implied by the name of the data. 
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Example 

Content-Type: application/x-up-device ;name-phonebook 

<raw data> 
Security Considerations 
Relative URLs 

Some of the security mechanisms in the browser are based 
on the accuracy of the URLs of cache entries. To prevent one 
service from spoofing another, all URLs in digest entries 
must be relative to the requested URL of the digest. This 
applies to the Content-Location headers of HDML entries, 
as well as to the URLs in the CacheOp and Alert entries. 

APPENDIX Al 

UP.Browser Functional Specification 
This appendix documents the external functional specifica- 
tion of the UP.Browser (browser 134). 
This section covers the design and specification of the two 
languages, HDML and compiled (binary tokenized) HDML, 
used in the UP.Link system (link station 124). Differences 
from 1.0 client implementations are noted. 
What is HDML? 

HDML stands for Hand-held Device Markup Language. 
HDML is not a markup language but its syntax is loosely 
based on HTML, HperText Markup Language. HDML is a 
language for describing the user interaction with information 
in UP.Link 124. HDML is written by service providers as a 
way of describing the service application. It includes infor- 
mation both for the end user and for the server software. 
HDML is also generated by service providers' programs 
dynamically. Compiled HDML is a distillation of HDML 
and describes the same interactions to the actual phone 
device. Compiled HDML is primarily a binary tokenization 
of the information in HDML. However, some features are 
more dramatically transformed in the conversion from 
HDML to compiled HDML (for example, all images are 
in-lined in compiled HDML). 

The bulk of this report is a description of HDML. In general, 
this description directly applied to compiled HDML by 
substituting compiled HDML's binary tokens for HDML's 
ASCII tokens. There is a conversion chart for tokens at the 
end. Any structural differences in compiled HDML are 
noted. 

UP.Link Gateway Protocol 

1 Connectionless UGP Overview 

UP.Link Gateway Protocol, UGP, is the application protocol 
that is used to format and interpret communications between 
the Client and the UP.Link. FIG. 3 is a schematic diagram of 
a UGP operational model. Connectionless UGP sits between 
the Client and UDP within the mobile device, and between 
the Agent/Messenger and the UDP within the UPGateway, 
i.e. link station 124. Operations initiated by the Device 120, 
referred to as Client Requests, are transactional in nature. 
Operations initiated by the UPGateway, referred to as 
Notifications, follow the performer/invoker remote invoca- 
tion model. Tliese 2 types of communications are funda- 
mentally different. For the sake of clarity, they are described 
independently in the following sections. The last section 
describes the layout of the protocol \mits at an attribute and 
byte level, 
1,1 Client Requests 

Client Requests are initiated by the client in response to user 
input. Typically, the user presses a key on the keypad in 
response to a system prompt. The keypress is translated into 
a Client Request which is sent to the UPGateway for 
processing. Client Requests follow a client/server transac- 
tional model- This model has been implemented using a 
request, reply, acknowledgment client/server interaction. 
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FIG. 4 depicts the typical transaction. A Client Request is 
made to the UPGateway. The UPGatcway processes the 
request and returns a reply. The Client responds with an 
acknowledgment to inform the UPGateway that the reply 
has been received successfully. 

1.1.1 Client Request 

A Client Request is issued by the Qient in response to user 
input on the device's key-pad. The Client translates the 
keypress into a URL that conforms to the HDML standard. 
The URL is passed to the UGP client layer, as an invoke - 
request, where it is packed into a Request PDU and sent to 
the waiting UPGateway. 

1.1.2 Reply 

The UPGateway constructs, validates, and compresses the 
reply into TIL which is passed to the UGP server layer where 
it is packed into a Reply PDU and sent back to the Client. 
The UGP client layer matches the Reply to a pending 
Request through use of a transaction identifier. Once the 
Reply is received, it is posted within the client as a result- 
indication. 

1 .1 .3 Acknowledgment 

The UGP Client layer sends an acknowledgment to all 
result-requests by the UPGateway. This tells the UPGateway 
that the Reply has been successfully delivered and the 
UPgateway can free all state associated with that Request. 
The acknowledgment contains the number of milliseconds 
between the time the Request was issued to the time the 
response was received. This number is the perceived user 
delay and is logged with each transaction. 

FIG. 4 describes the "perfect world" in which everything 
happens within the proper amount of time and produces no 
error conditions. The full picture is a little more complicated 
as you can see from the FIG. 5. 

Unreliable transports, such as UDP, require the applica- 
tion protocol to account for packet sequencing and retrans- 
mission. This puts the burden on the UPGateway to resend 
packets that it thinks might have been lost in transmission. 
The process is shown in FIG. 6. 

In FIG. 6, for each transition number, the corresponding 
actions are listed below: 

1) . Send Request: 

Increment and assign reference number 

Set retransmission timer for CLNT__WAIT_TIME 

Initialize retransmission counter 

Send request PDU. 

2) . Request Retransmit: 

Retransmit request PDU while number of retransmissions 

is less than MAKJETRANSMISSIONS 
Increment the retransmission counter. 

3) . Request Time-out: 
Send cancel PDU 
Post a time-out error. 

4) . Reply Received: 

Send reply acknowledgment PDU. 
Remove retransmission timer 
Post reply 

5) . Error Received: 

Send reply acknowledgment PDU. 
Remove retransmission timer 
Post error. 

6) . Hold On Received: 
Remove retransmission timer 

Set retransmission timer for CLNT_WAIT_TIME*3 
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7) . Duplicate Reply/Error Received: 
Send reply acknowledgment PDU, 

8) . Request Canceled: 
Remove retransmission timer 

5 Send cancel PDU. 

1.1.4 Request PDU Retransmit 

UGP calls for the retransmission of a Client Request if a 
response has not been received within a certain amount of 
time. The actual amount of time is a tunable parameter that 

10 should be set somewhere between 5-15 seconds. These 
retransmissions will continue tmtil either the request is 
canceled by the user, or a response is received. 
The fact that the response is not received within the proper 
amount does not necessarily mean that the Request packet 

15 has been lost. The request could be asking for service from 
a machine that is slow, or down. In that case, the retrans- 
mission of the original request every 10 seconds will cause 
a great deal of unnecessary communications between the 
Client and UPGateway. The user is paying for each of these 

20 transmissions by the byte and could rack up a great deal of 
service usage simply in waiting for a request to be pro- 
cessed. 

1.1.5 Hold On 

A Request acknowledgment scheme has been implemented 
25 to prevent this continuous stream of frequent retransmis- 
sions. The Request acknowledgment, or Hold On, is sent by 
the UPGateway to the Client to inform it that the Request 
has anived successfully and any further retransmission is 
unnecessary. 

30 The Client never completely trusts the UPGateway to fulfill 
its obligations, even after it knows the Request was suc- 
cessfully received. The Hold On packet simply tells the 
Client that it should wait a little longer before checking on 
the Request's status. This is done to prevent deadlock in the 

35 event that the UPGateway has a catastrophic failure. The 
Hold On period is also a tunable parameter and should be set 
somewhere between 4-12 seconds. The UPGateway will 
continue to send HoldOn packets on an extended schedule as 
long as the response packet has not been fully constructed. 

40 When everything is working perfectly, all client resends will 
be preempted by HoldOn's from the UPGateway. 

1.1.6 Error PDU 

A Client Request can fail for any number of reasons. The 
requesting user may not be registered, the requested service 
45 may not be registered or available, the service's response 
may not be valid. These conditions are reported to the Ghent 
through an Error response. 

An Error response comes in lieu of a Reply. The Error 
response is associated with the outstanding Request through 

50 use of its sequence number. The Error response is an 
informational message directed at the user. The Client 
cannot take appropriate corrective action on the user's 
behalf, and there is no attempt to do so. The error messages 
are simply displayed to the user and must be considered part 

55 of the user interface. 

1.1.7 Request Cancellation 

UGP allows the Client to cancel a Request both explicitly 
and implicitly. UGP includes a Cancel PDU that the Client 
can send to cancel the current request. Again the UGP 

60 transaction identifier is used to pair the Cancel request with 
the appropriate Client Request. Explicit cancellations do not 
have a built in acknowledgment mechanism. This is due to 
the fact that they are issued in response to the user giving up 
on the current Request and will typically be followed shortly 

65 by a new request. The next request acts as an implicit 
cancellation, as is shown in FIG. 7 and explained in the 
following description. 
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Requests are cancelled implicitly by issuing another 
Request, If the UPGateway receives a new Request from a 
Client while it is processing the old one, the old one is 
cancelled and the new one takes its place. 
For each transition number in FIG. 7, the corresponding 
actions are listed below: 

1) . Request Received: 
Extract REF_NO 

Issue INVOKE-indication. 

2) , Send Reply/Error; 
Assign REF_>JO 
Transmit Reply/Error PDU 

Set retransmission timer for SVC_WAIT_TIME 
Initialize retransmission counter, 

3) . Acknowledgment Received: 
Remove retransmission timer 
Issue RESULT-confirm 

Release state associated with REF_NO. 

4) . Duplicate Request Received: 
Send Hold-on PDU. 

5) . Reply Retransmit; 

Retransmit Reply/Error PDU while number of retrans- 
missions is less than MAX_RETRANSMISSIONS 
Increment the retransmission counter. 

6) . Duplicate Request Received; 
Transmit Reply/Error PDU. 

7) . Time-out: 

Issue FAILURE-indication. 

8) . New Request Received: 
Issue CANCEL-indication 

Release state associated with REF_NO 
Extract REF_NO from new request 
Issue INVOKE-indication. 

9) . Cancel Received; 

Issue CANCEL-indication 
Release state associated with REF_NO. 
1,1.8 Reply Retransmit 

Just as the Client retransmits the initial Request in order to 
ensure it is received, the UPGateway retransmits the 
response several times in an effort to get it to the waiting 
Client. Once the Client receives the response it is required 
to send an Acknowledgment to complete the transaction. 
ITie number of times the UPGateway retransmits, and their 
frequency, are tunable parameters which default to 3 times 
and 10 seconds respectively. 
1.2 Notifications 

Notifications are communication between the client and a 
Service which are initiated by the Service. They are used to 
deliver asynchronous events that happen outside of the 
standard Client Request/Reply scenario. An example of this 
type of event is the arrival of an email message in the user's 
mailbox. The message service managing the user's mailbox 
has the option of forwarding the entire message to the 
device, forwarding a portion of the message, or just turning 
the message light on in the device. In order to perform any 
of these operations, the service must be able to deliver 
asynchronous notifications to the Client. 
FIG. 8 depicts the UGP notification time line. The Service 
begins the sequence by issuing a NOTIFICAnON-request, 
through the RFC interface, to the UPGateway. The UPGate- 
way stores and delivers its content to the Client. The Client 
responds by returning an Acknowledgment PDU back to the 
UPGateway. If the Client does not acknowledge the 
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Notification, the UPGateway will continue to retry the 
delivery procedure for some period of time. The delay 
between delivery cycles follows an exponentially increasing 
retry dependent curve. This retry mechanism is necessary to 
5 account for the possibility that the device might be turned off 
or out of range. The Notification interaction does not include 
a 3 -way handshake like the one employed by the Client 
Request. The UPGateway assumes that each notification 
stands on its own, and that the Client can deal with duplicate 
transmissions. 

1.2.1 Notification Objects 

The Service uses the RPC interface class to deliver a 
NOTIFICAnON-request to the UPGateway. The UPGate- 
way is listening on a well-known address for incoming 
notifications. Notification objects delivered to this address 
15 are scheduled for delivery, and placed in the UPGateway 's 
delivery queue. 

1.2.2 Notification 

The Notification message is similar in format and function 
to an RPC request. The Notification PDU contains a proce- 

20 dure number within the Client application where the noti- 
fication body should be delivered. The Notification body is 
an opaque block of data of up to 1400 bytes. No assumptions 
are made by the UPGateway or UGP about the contents of 
the body so the Client is responsible for performing any 

25 necessary validation. 

1.2.3 Acknowledgment 

The Client UGP layer sends an Acknowledgment PDU in 
response to each arriving Notification. The Acknowledg- 
ment simply means that the Notification was delivered 
successfully. No other information is implied by an 
Acknowledgment. 

Services and Client applications that wish to implement a 
request/response paradigm on top of Notifications must use 
Chent Requests to do so. 

1.2.4 Error 

35 The UPGateway will continue to retry the delivery of each 
outstanding notification for some period of time, after which 
the notification is rejected back to the sender. The period of 
time is dependent upon the value of MTTL which is supphed 
be the service when submitting the notification. If the 

40 notification is not delivered within the specified MTTL 
period, the originating service will receive a reject notice 
from the UPGateway. The notice will include a reject 
justification as its message body. 
PDU Descriptions 

45 UGP is an application protocol that has been built on top of 
the LSROS standard. The LSROS standard defines 5 base 
PDU types, the Cancel type is a UGP specific extension: 
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TABLE Al.l. 




LSROS Catceorics 


Code 


PDU Name 


0 


Invoke 


1 


Result 


2 


Error 


3 


Acknowlcdgpicnt 


4 


Failure 


5 


Cancel 



60 UGP is organized around these 6 categories of PDUs. UGP 
defines a number of packet types that fall into the Invoke and 
Result categories, so it was necessary to supplement the 
LSROS header with additional UGP header bytes to accom- 
modate the additional types. 

65 The following section describes the byte level format of 
each of the UGP PDUs. The descriptions are grouped by the 
LSROS category to which they belong. 
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13.1 Invoke 

ITie LSROS Invoke PDU header consists of 3 bytes that are 

formatted as shown in FIG. 9. 

In FIG. 9, various fields are described as follows: 

SAP — 4 bit Service Access Point is the LSROS identifier 
for UP.Link service. 

Reference ID— 8 bit identifier 

Encode T^pe — Parameter encoding type. 

Operation Value — Subtype within the invoke category 

TABLE A1.2. 



UGP Invoke PDU Operation Values 


Invoke Type 


UGP Name 


1 


Request 


2 


Start-up 


3 


Sync 


4 


Notify 



TABLE A1.2 lists the UGP PDU operation values that fit 
within the LSROS Invoke category. The following sections 
describe each of these UGP PDU types. The shaded areas in 
the figures represent the LSROS header portion of the PDU. 

1.3.1.1 Request 

FIG. 10 shows the structure of a Request PDU, which 
consists of 2 components: 

1) . An LSROS Invoke header 

2) . Up to a 1460 byte URL component. 

1.3.1.2 Start-up 

FIG. 11 shows the structure of a Start-up PDU, which 
consists of 3 components: 

1) . An LSROS Invoke header 

2) . A six byte code identifying the device model. 

3) . Up to a 1454 byte URL component. 

1.3.1.3 Sync 

FIG. 12 shows the structure of a Sync PDU, which consists 
of 2 components: 

1) . An LSROS Invoke header 

2) . A six byte code identifying the device model 

1.3.1.4 Notify 

FIG. 13 shows the structure of a Notify PDU, which consists 
of 4 components: 

1) . An LSROS Invoke header 

2) . A four byte sequence number that can be used to uniquely 
identify the notification. 

3) . A one byte notification type that is defined by the service 

4) Up to 1454 bytes worth of notification content. 
1.3.2 Result 

The LSROS Result PDU header consists of 3 bytes that are 
formatted as follows: 

FIG. 14 shows the structure of a LSROS Result PDU, of 
which the fields are described as: 
Encode Type — Parameter encoding type. 
Reference ID — 8 bit identifier 

Operation Value — Subtype within the Result category 



each of these UGP PDU types. The shaded areas in the 
figures represent the LSROS header portion of the PDU. 

1.3.2.1 RequestReply 

FIG. 15 shows the structure of a RequestReply PDU, which 
consists of 2 components: 

1) . An LSROS Result header 

2) . Up to a 1460 byte TTL component. TIL is a compiled and 
compressed version of HDML. 

1.3.2.2 StartupReply 

10 FIG. 16 shows the structure of a StartupReply PDU, which 
consists of 3 components: 

1) . An LSROS Result header 

2) . A four byte limestamp containing the value of time in 
seconds since 00:00:00 UTC, Jan. 1, 1970. 

3) . Up to a 1456 byte TIL component. TIL is a compiled and 
compressed version of HDML. 

1.3.2.3 SyncReply 

FIG, 17 shows the structure of a SyncReply PDU, which 
consists of 2 components: 

1) . An LSROS Result header 

2) . A four byte timestamp containing the value of time in 
seconds since 00:00:00 UTC, Jan. 1, 1970. 

1.3.2.4 NotifyReply 
FIG. 18 shows the structure of a NotifyReply PDU, which 

consists of 2 components: 

1) . An LSROS Result header 

2) . A four byte sequence number that can be used to 
uniquely identi^ the notification. 

1.3.2.5 Redirect 
FIG. 19 shows the structure of a Redirect PDU, which 

consists of 2 components: 

1) . An LSROS Result header 

2) . A six byte address that contains a 4 byte internet 
address and 2 bytes of port number, all in network byte 
order. 

1.3 Enor 

The LSROS Error PDU header consists of 2 bytes that are 
formatted as shown in FIG. 20. 

The LSROS error header is followed by a string of up to 
40 1464 bytes in length. 
1.3.4 Acknowledgment 

The LSROS Acknowledgment PDU header consists of 2 
bytes that are formatted as shown in FIG. 21. The LSROS 
Acknowledgment PDU bas the following components: 
45 1) Ack Type — Either a reply acknowledgment or Holdon. 

2) Reference ID — 8 bit identifier 

TABLE Al. 4 
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TABLE Al .3 
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UGP Result PDU ODcration \^lues 


Invoke TVpe 


UGP Name 


5 


RequestReply 


6 


StartupReply 


7 


SyncReply 


S 


NotifyReply 


9 


Redirect 



LSROS Ack types 
Ack Type UGP Name 



Ack 
Holdon 



TABLE A1.2 lists the UGP PDU types that fit within the 
LSROS Result category. The following sections describe 



TABLE Al. 4 lists the LSROS Ack types that fit within the 
LSROS Ack category. The following sections describe each 
of these PDU types. The shaded areas in the figures represent 
the LSROS header portion of the PDU. 
60 1.3.4.1 Reply Acknowledgment 

FIG. 22 shows the structure of a Reply Acknowledgment 
PDU, which consists of 3 components: 

1) . An LSROS Ack header 

2) . A four byte field containing the number of milliscc- 
65 onds since the request was issued by the client device. 

3) . A one byte field containing the number of retries the 
client performed before the result arrived. 
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1.3.4.2 Holdon 

FIG. 23 shows the structure of a Holdon, which is fully 
contained within the LSROS header. 
1.3.5 Failure 

The LSROS Failure PDU header consists of 3 bytes that 5 
are formatted as shown in FIG. 24. The failure values are 
listed in the following TABLE A1.5. 



TABLE Al .5 





LSROS Failure \^lucs 




Meaning 


0 


Transmission failure 


1 


Out of local resources 


2 


User not responding 


3 


Out of remote resources 



10 



1.3.6 Cancel 

The Cancel PDU header consists of 2 bytes that are 
formatted as shown in FIG. 25. 

APPENDIX A2 

SUGP Protocol Specification 

25 

This appendix is a specification for SUGP protocol. 
2.1.0 Project Summary 

SUGP (Secure UP. Link Gateway Protocol) is an applica- 
tion protocol for remote operations between an UP. Browser 
and an UP.Link. It provides a mechanism for requests, 
replies, message privacy, message integrity, session, 
authentication, notifications, and automatic configuring. 

SUGP is the next generation of UGP, or ANTP. FIG. 26 
is a schematic diagram of a data network using SUGP 
Protocol. 35 

2.2.0 Features, Goals and Requirements 

2.2.1 Goals and Requirements 

Interactive requests/replies between an UP.Browser and 
an UPLink 

Secure communication between an UP.Browser and an 40 

UPLink 
Support for authentication 

Support for automatic configuring of an UP.Browser 
Support for notifications 

2.2.2 Assumptions 
UDP is assumed as the primary communication transport 

mechanism between an UP.Browser and an UP.Link. 
Encryption and key exchange algorithms do not impose 
extremely diflBculties in performance and memory size so 
requirements for the device. 

2.2.3 Features 

A set of Protocol Data Unit (PDU) definitions Compared 
to UGP, SUGP has additional PDU's to handle secure 
communication, session creation, support for automatic 55 
provisioning/configuring, and support for service cre- 
dential. The following is a list of all PDU's. 

Session Request 

Session Reply 

Session Complete 60 
Service Request 
Service Reply 

Extended Service Request Extended Service Reply Key 
Request 

Key Reply 65 

Signal 

Get Notify 
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Notify Reply 
Post 

Redirect 
Error 
Cancel 
Ack 

Hold On 

The protocol is no longer built on top of LSROS. The 
protocol PDU encoding will be optimized for UP.Link 
architecture. 
An API for the protocol 

Because the protocol PDU has been redefined, the 
corresponding API is also redefined. However, 
SUGP API preserves the basic features in UGP API 
such as objected oriented API functions and buffer 
manipulation API. Like UGP API, SUGP API is a 
direct API on top of the protocol PDU. All function 
names are different from UGP API. 
SUGP API has a set of setter's and getter's common for 
all PDU types and for each individual PDU types. 
There are also APFs for encryption and decryption. 
Message Privacy between an UP.Browser and an UP.Link 
All PDU's are encrypted except that certain fields of 
session creation PDU's must be sent in clear text. 
Message Integrity between an UP.Browser and an 
UPLink 

Message integrity are enforced by using check-sum for 
the entire PDU. The checksum is then encrypted 
together with the PDU. 
Counteracting Playback Attacks 

Playback is a very common security attack. The pro- 
tocol provides the means to counteract playback 
attacks. The proposed approach is to use request Id 
to detect playback requests for normal requests. The 
request Id is encrypted in the protocol PDU, Every 
request and reply must carry a request id. During the 
life time of a session, any request id in requests/ 
replies must equal to the current request id in both 
server and client. 

For the session creation process, both client and server 
challenge each other by using a nonce as a challenge 
and nonce+1 as a response to the challenge to avoid 
playback of session creation requests. 
Session based request/reply model 

All the requests and replies must be associated with a 
session context (either a server session context or a 
client session context). The requests normally carry 
a 4 byte server session id. A session creation request 
is associated with a special session with sid=0. The 
client is typically considered to have 2 sessions: 
session with encryption and session without encryp- 
tion. 

Session creation and authentication 

All the sessions are authenticated. The session authen- 
tication between an UP.Browser and an UP.Link is 
conducted by using shared secret key between them 
and a nonce challenge. 

As part of the session creation process, version, cipher 
choice, and device type for the session are associated 
with the session context. 
Automatic configuring support 

The protocol supports distribution of permanent shared 
secret key from an UPLink to an UP.Browser, when 
the device is first activated. Diflie-Hellman key 
exchange protocol is used in tlie process to securely 
distribute the shared secret key to the device after 
appropriate authentication. This is an one time pro- 
cess. 
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Request Piggybackiag 

The session creation process requires the cUent to send 
at least two messages (Session Request and Session 
Complete) to the server to complete the session 
creation. The second message (Session Complete) 
can piggyback a normal request. 

Vcrsioning 

Although backward compatibility for the current prod- 
uct is not required, the protocol provides version 
control mechanism, so that the protocol can be 
implemented to be backward compatible or forward 
compatible in the future. The proposed approach is to 
add a version number in the session creation PDU's. 
Version is thus associated with a session context. 
Different block cipher algorithms support 

The protocol provides means to support different cipher 
algorithms. As part of session creation request, the 
browser indicates its cipher choice. 

URLink must support multiple block cipher algorithms 
for different sessions. However, Version 2.0 will not 
implement multiple block cipher algorithms. Only 
RCS is implemented. This is a long term feature. 
Service credential support 

The protocol allows UP. Browser to authenticate itself 
to a service by UlD/password. The proposed method 
is to let UP.Link return an error deck to UP. Browser 
Compression 

Compression is considered in the design but is not 
planned for Version 2.0 implementation. 

2.3.0 Application Programming InterfaceSUGP is the next 
generation of UGP. Although there are many new 
capabilities, API for SUGP is conceptually similar to API for 
UGP. The following describes similarities and differences 
between SUGP API and UGP API. For those who wish to see 
the complete API definitions, please refer to sugp.h. 

2.3.1 Similarities Between SUGP API and UGP(ANTP) API 
SUGP API is also a direct interface on the protocol 

PDU's. There are setter's and getter's functions to 
construct/consume the protocol PDU's. For instance, 
SugpGet-SessionldO, SugpGetDigestO, and SugpSe- 
tRequestldO. The complete definitions for all the set- 40 
ter's and getter's are provided in sugp.h. 
SUGP API expects the upper layer application to allocate/ 
free memory buffers for constructing and receiving 
protocol PDU's. 

2.3.2 Differences Between SUGP API and UGP (ANTP) 
API 

SUGP API has a complete new set of protocol PDU types 
and function names. 

Both UP. Browser and URLink must maintain session 
contexts. A session context may typically contain IP jq 
address/subscriberlD/devicelD, session keys, version 
info, cipher choice, and device type. Once a session is 
established, subsequent protocol PDU's do not carry 
the session wide information any more because they are 
in the session context. 

Server has a notion of session id to identify a session 
context. The server session id is defined as an unsigned 
integer of 4 bytes. The session id's are never encrypted 
and are used to get session context from the session 
table. Values 0-15 in the server session id space are 
reserved for special "sessions" such as session creation. 
The browser only has one session context so that there 
is no need for session id. 

Encryption/Decryption functions are introduced to 
encrypt/decrypt the protocol PDU*s. Both encryption 
and decryption functions require keys. Those functions 
also generatcA^erify checksum's for message integrity 
and may perform compression. 
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Both URBrowser and UP.Link should have no problem 
to provide session keys for sending a PDU. For 
receiving a PDU, the upper layers do the following 
to look up a session key. 
Client: Receive first, get the unique session key. 
URLink: Receive first, use Sessionid to look up the 
session key. 

2.4.0 Protocol PDU DefinitionsThis chapter describes the 
SUGP PDU (Protocol Data Unit), which is the data format 
to be exchanged between an URBrowser and an UP.Link. 
The Name column in several of the PDU definition tables 
often have encryption applied. 

2.4.1 IntroductionEvery PDU has a Header and a Body. A 
header is followed by the Body which contains the PDU type 
specific content. ITiere are two kinds of headers: Long- 
Header and Short-Header. Long-Header has 5 bytes and is 
destined to servers. Short-Header has 2 bytes and is destined 
to clients. MAX-LEN is the maximum length of the entire 
PDU, which typically is the MTU of UDP minus the 
overhead for encryption. Tlie lengtli of a Body can be up to 
MAX LEN - Header. The structure of a long header and a 
short header is shown in FIG. 27. 

2.4.2 PDU I^ng-HcadcrThe Long-Header is for PDU's 
destined for an UP.Link. It has a server semantics because 
only servers will receive those PDU's and process them 
accordingly. The Long Header format is shown in Table 
A2.1. 

TABLE A2.1 





Lone- Header Format 


Name 


Length 


Purpose 


Sessionid 


4 bytes 


Identifies session in the 






server session context table 


requestid 


1 byte 


identifying a request. Used for 






counteracting playback attack 



Comments: 

Sessionid value OxOOOOOOOO-OxOOOOOOOF are reserved 
for special purposes. Currently, 0x00000000 is used to 
indicates that PDU is not encrypted at least for the 
following: 
Long-Header; 
Type in the Body; 
This is currently only used for session creation. 
OxOOOOOOOl-OxOOOOOOOF are reserved for future use. 
requestid is also used to identify duplicated requests due 
to client retransmission. 
2.4.3 PDU Short-HeaderThe Short-Header is for PDU's 
destined for clients. It has a client semantics because only 
client will receive those PDU's and process them as either 
replies, errors, or notifications. The Short Header format is 
shown in Table A2.2. 



TABLE A2.2 
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Short-Header Format 


Name 


Length 


Purpose 


session 


1 byte 


indicates session context 


requestid 


1 byte 


identifying n request. Used 






for counteracting playback 






attack 



Comments: 

session values are allocated as: 

0 — no encryption (for some special PDU's and enor 
PDU with certain error codes); 

1 — encryption with Shared Secret Key (for session 
reply and error PDU with certain error codes); 
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Status 



Name 


Bit 


Purpose 


SYNC 


0 


if 1, indicates to get time and 






check if notification is pending 


NTFY 


1 


if 1, indicates notification pending 


ACCEPT 


2 


if 1, indicates that client accepts 






server proposed cipher 


reserved 


3 -- 
7 


reserved for future use 



TABLE A2.4 



Session Request 



Name 


Length 


V^lue/Puipose 


type 


1 byte 


1 


cipher 


2 byte 


cipher: algorithms and parameters, 






NBO 


version 


1 byte 


SUOF protocol version 


locale 


1 byte 


localizatioD support 


dcviceType 


6 bytes 


device type: hardware/software 






type/version for device 


deviceld_len 


1 byte 


length of device id 


deviceld 


variable 


device identifier up to 255 bytes 






long 


cnonce 


2 bytes 


client nonce challenge to server 






for authentication, NBO 
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2 — encryption with session key (for reply / error PDU 

within a normal session); 
others — reserved for future use; 
requestid is also used to identify duplicated replies due to 
server retransmission. r 
2.4.4 PDU Body 

Type specific contents are defined as Bodies. Every 
Body's first byte is the type or a tag of a Body, which 
identifies the type of operations the PDU is entitled to. 
Everything begins at the second byte are type specific 
content, which are referred to as Content from now on. The lO 
structure of a PDU Body used in SUGP is shown in FIG. 28. 
Comments: 

The highest bit in Type is used (when it is set to 1) for: 
an Ack for n-1 request's reply where n is the current 
request's id for Long PDU's; this makes possible for 15 
the client to piggybacking Ack's; 
indicating if compression is on for Short PDU's; 
2,4.4.1 Status 

Status is a bit mask of one byte. It is a modifier for 
selected reply PDU's so that certain conditions are indicated jo 
to the client. Tkble A2.3 lists status values. 

TABLE A2.3 



cipher encoding: 1st byte is the code for combination of 
algorithm and configuration. For instance, value 0x01 
is for RC5 with word size 32 bits, key size 16 bytes, and 
variable rounds. 2nd byte is the additional parameter as 
needed for the 1st byte. If 1st byte's value is 0x01, 2nd 
byte is the number of rounds for RC5. The meaning of 
2nd byte depends on the code for the Isl byte. 
2.4.4.3 Session Reply 

The data structure of a Session Reply is listed in TABLE 
A2.5. Purpose: Server response to a Session Request. 

Header Type: Short 

Source: UP.Link 

Destination: client 

TABLE A25 

Session RcdIv 



25 



4.4.2 Session Request 35 

The data structure of a Session Request is listed in TABLE 
A2.4. F*urpose: Create a session. 

Header Type: Long 

Source: client 

Destination: UP.Link 

40 



Name 


Length 


\^lue/Piiipose 


type 


1 byte 


10 


limit 


1 byte 


security violation count limit 






(e.g., decryption feilures) 


sessionld 


4 bytes 


session Id identifying session 






context in UF.Unk, NBO 


cipher 


2 bytes 


cipher confirmation, NBO 


cnonccplus 


2 bytes 


sty rspns to nonce challenge to 






satisfy authentication, NBO 


snotince 


2 bytes 


server nonce challenge to the 






client for authentication, NBO 


bootinfo_len 


2 byte 


bootinfo length, NBO 


key_len 


1 byte 


key length 


displist_count 


1 byte 


number of dispatcher IP 






addresses in displist 


key 


variable 


session key 


boo tin fo 


variable 


bootstrap info (e.g., home page 






URL, etc.) 


displist 


variable 


array of IP addresses (6 bytes 






each) for dispatchers 



a. NBO stands for Network Byte Order 

Comments: 

This PDU is not encrypted up to device Id field. The 
session Id in the Long Header is 0 to indicate that this 
PDU is partially encrypted. 

version is encoded as MAJOR:MIN0R (4:4). The poli- 
cies for backward/forward compatibility can be deter- 
mined in the future. 

UP.Link accepts "NoEncryption" only if UP.Link is con- 
figured so. This normally assumes that the operating 
environment is secure. 
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Comments: 

The long sessionld in the above table is the server session 
id which identifies the session context for the session 
just created in the server. The client saves this sessionld 
in its corresponding session context. From this point 
on, any requests to the server will use the 4 byte server 
sessionld in the Long -Header. 

displist is a list of dispatchers. The purpose is for higher 
availability and load balancing. The browser is initially 
provisioned with a single IP address for a dispatcher. 
That dispatcher may return a list of other dispatchers 
for client's future use after the first session is estab- 
lished. The browser sequentially picks the next IP 
address from the hst for the next new session. 
2.4.4.4 Session Complete 

The data structure of a Session Complete is listed in 
TABLE A2.6. 

Purpose: Complete the session creation process. 

Optionally, a request PDU may be piggybacked. 

Header Type: Long 

Source: client 

Destination; UP.Link 

TABLE A2.6. 



Session Comptete 



Name 



Length 



Value/Puipose 



type 

snoncceplus 



1 b>ae 

2 bytes 



8 

dnt response to srv nonce 
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TABLE A2.6,-continuecl 



Session Complete 



Name 


Length 


Wuc/Purpose 






challenge to satisfy 






authentication, NBO 


length 


2 byte 


length for the following variable 






length field; net byte order, NBO 


status 


1 byte 


ACCEPT indicates that client 






accepts server proposed cipher. 


request 


variable 


a piggybacked request FDD 



5 



2.4.4.5 Service Request 

The data structure of a Service Request is listed in TABLE 15 
A2.7. 

Purpose: Service URL request to UP. Link. 
Header Type: Long 
Source: client 

Destination: UP.Link 20 
TABLE A2.7 

Service Request 
Name Length V^Iuc/Puiposc 

type 1 byte 2 

length 2 bytes the length of the following variable 

fteld, NBO 

serviceURL variable service URL 

30 

2.4.4.6 Service Reply 

The data structure of a Service Reply is listed in TABLE 
A2.8. 

Purpose: Return the digest from an UP.LINK to client. 35 
Header Type: Short 
Source: UP.Link 
Destination: client 

TABLE A2,8 4Q 



Service Reply 



Name 


Length 


\felue/Puipose 


type 


1 byte 


8 


length 


2 byte 


the length of the following variable 






field; NBO 


digest 


variable 


digest as a result of a URL Service 






Request 
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2.4.4.7 Extended Service Request 

The data structure of an Extended Service Request is 
Usted in TABLE A2.9. 

Purpose: Service URL request to UP.Link with additional 
information. 

Header Type: Long 

Source: client 

Destination: UP.Link 

TABLE A2.9 

Extended Service Request 



Name Length Vfelue/Puipose 



type 1 byte 3 

url_Icn 2 bytes length of URL, NBO 

hcader_len 2 bytes length of header, NBO 



36 

TABLE A2.9-continued 



Extended Service Request 



Name 


Length 


Value/Purpose 


status 


1 byte 


SYNC indicates get time and get 






notify status 


URL 


variable 


service URL 


header 


variable 


header such as origin URL 



2.4.4.8 Extended Service Reply 

The data structure of an Extended Service Reply is listed 
in TABLE A2.10. 

Purpose: Return the digest and additional information 
from an UP.Link to client 

Header Type: Short 

Source: UP.Link 

Destination: client 

TABLE A2.10 



Extended Service Reply 



Name 


Length 


Value/Purpose 


type 


1 byte 


3 


status 


1 byte 


NTFY indicates that notification 




pending 


time 


4 bytes 


time of the day, NBO 


length 


2 bytes 


the length of the following variable 






field, NBO 


digest 


2 byte 


the length of the following variable 






field, NBO 



2.4.4.9 Key Request 

The data structure of a Key Request is hsted in TABLE 
A2.n. 

F*urpose: Request for establishing a new shared secret key 
between UP.Browser and UP.Link. 
Header Type: Long 
Source: client 
Destination: UP.Link 

TABLE A2.11 



Key Request 



Name 


Length 


\^lue/Furpose 


type 


1 byte 


9 


param_Jd 


1 byte 


DH parameter set identifier 


deviceld_jen 


1 byte 


deviceld length 


keyData_Ien 


1 byte 


keyData length 


deviceld 


variable 


public key of the client 


keyData 


variable 


public key of the client 



Comments: 

not encrypted; 

sid==0; 
2.4.4.10 Key Reply 

The data structure of a Key Reply is listed in TABLE 
A2.12. 

Purpose: UP.Link returns its public key to complete the 
process for establishing a new shared secret key between 
URBrowser and UP.Link. 

Header Type: Short 

Source: UP.Link 
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Destination: client 






TABLE A2.12 




Key Rcplv 


Name 


Length 


Valuc/E*urposc 


type 


1 byte 


17 


keyData_len 


1 byte 


keyData length 


keyData 


variable 


public key of the server 



Comments: 
Not encrypted; 
sid— 0; 

24.4.11 Signal 15 
The data structure of a Signal is listed in TABLE A2.13, 
Purpose: UP.Link (e.g., UP.Link Messenger) signals a 

device for notifications. 
Header Type: Short 

Source: UP.Link 20 
Destination: client 



TABLE A2.13 




Signal 




25 


Name 


Length 


V^luc/Purpose 




type 


1 byte 


16 





Comments: 

Signal is not encrypted. 

sid is set to 0 in the header. 
2.4.4.12 Gel Notify 

The data structure of a Get Notify is listed in TABLE 
A2.14. 

Purpose: client gets next notification after receiving a 
Signal PDU. 

Header Type: Long 
Source: client 
Destination: UP.Link 
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TABLE A2.14 





Get Notify 




45 


Name 


Length 


V^Iue/Purpose 




type 


1 byU 


5 





2.4.4.13 Notify Reply 50 

The data structure of a Notify Reply is listed in TABLE 
A2.15. 

Purpose: reply for Get Notify. 
Header Type: Short 

Source: UP.Link 55 
Destination: client 



TABLE A2.15 



Notify Reply 



60 



Length 



V^lue/Purpose 



type 
status 

ntfy_id 
urLJcn 



1 byte 13 

1 byte NTFY indicates more notification 

pending 

4 byte2 unique notification id, NBO 

2 bytes url length, NBO 
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TABLE A2.15-contiiiued 







Notify RcdIv 


Name 


Length 


Value/Puiposc 


contcnt_Jcn 


2 bytes 


content length, NBO 


url 


variable 


base URL length 


content 


variable 


content digest 



10 



Comments: 

status==NTFY indicates more notifications pending, 
which makes chained fetching of notifications possible, 
base Url is used for security. 
2.2.4.14 Post 

The data structure of a Post is listed in TABLE A2.16. 
Purpose: client post data to UP.Link to perform HTTP 
Post. 

Header Type: Long 
Source: client 
Destination: UP.Link 

TABLE A2.16 



Post 



Name 


Length 


Value/Purpose 


type 


1 byU 


4 


url_Jcn 


2 bytes 


URL length, NBO 


data_lcn 


2 bytes 


Data length, NBO 


header_Jen 


2 bytes 


header length, NBO 


URL 


2 bytes 


URL 


Data 


variable 


data to be posted 


header 


variable 


header 



2.4.4.15 Redirect 

The data structure of a Redirect is listed in TABLE A2.17. 
Purpose: Redirect a client to another UP.Link. 
Header Type: Short 
Source: UP.Link 
Destination: client 



TABLE A2.17 







Redirect 


Name 


Length 


Value/Purpose 


type 


1 byte 


18 


address 


6 bytes 


4 byte IP address followed by 2 byte 






port number, alt NBO 



Comments: 

Redirect PDU is not encrypted. The redirected UP.Link 
will be authenticated by the client during the session 
creation process by the Shared Secret Key. 

Only Session Request can be redirected; 

sid=«=0; 
2,4.4.16 Enror 

The data structure of an Error is listed in TABLE A2.18. 
F*urpose: Return errors to a client from an UP.Link. 
Header Type: Short 
Source: UP.Link 
Destination: client 
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TABLE A2.18 



Error 



Name 


Length 


\^lue/Purpose 


type 


1 byte 


14 


code 


2 bytes 


eiroi code, NBO 


length 


2 bytes 


length of the following variable 






fteldl. NBO 


eirorDigest 


variable 


HDMLC digest carrying error 






messages/actions 



2.4.4.17 Cancel 

The data structure of a Cancel is listed in TABLE A2.19. 
Purpose: Cancel a request 
Header Type: Long 
Source: client 
Destination: UP.Link 



TABLE A2.19 



10 



IS 



20 





Cancel 






Name 


Length 


V^lue/Purpose 




type 


1 byte 


6 


25 



2.4.4.18 Ack 

The data structure of an Ack is listed in TABLE A2.20. 
Purpose: Acknowledge receipt of the replies from 
UP.Link. 

Header Type: Long 
Source: client 
Destination: UP.Link 
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TABLE A2.20 



35 







Ack 


Name 


Length 


Value/Purpose 


type 


1 byte 


7 


delay 


2 bytes 


round trip time for a request 


tries 


1 byte 


number of times the client retransmitted 




the request 



Comments: 

Ack can be sent alone when acknowledge is required, but 
the highest bit in the Type field for the request PDU's 
should be used instead to acknowledge n-1 request's 
reply whenever possible, where n is the current request 
id; 

2.4.4.19 Hold On 

The data structure of a Hold On is listed in TABLE A2.21 . 

Purpose: An UP.Link deters a client for retransmission of 
a request while the request is in process, longer than normal 
process time. 

Header Type: Short 

Source: UP.Link 

Destination: client 



45 



50 



55 





TABLE A2.21 




60 




Hold On 






Name 


Length 


V^lue/Purpose 




type 


1 byte 


15 


65 
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2.5.0 Protocol Operations 

This section describes how to use the SUGP protocol 
PDU's to perform higher level tasks such as session creation 
and client requests. 

2.5.1 Session 

Every request and every reply are associated with a 
session context. The session context may typically contain 
the following information: 

Session Id 

Session Key 

Cipher 

Protocol Version 
Request Id 
device Id 
device type 

Server session Id is an unsigned long of 4 bytes. Both 
client session and server session serve the same purpose: 
associate information for a particular communication 
instance between a client and a server. Because the client 
only has one session, the session id is not required, but the 
notion of a session exists. 

SUGP reserves 0-15 for server session id's for special 
purposes (e.g., session creation). Although only O's are used 
in server currently, the others may be used for other special 
purposes in the future. 

Server is expected to serve many devices so that its 
session table of session contexts is large. The implementa- 
tion for server session contexts is expected to be RDBMS 
tables with an index on Session Id. 

2.5.2 Session Creation 

An UP.Link session creation process is initiated by a 
browser which wishes to establish a secure communication 
channel with an UP.Link. FIG. 29 shows the sequence of 
events during the session creation process between a 
browser and an UP.Link. 

In FIG. 29, (X)K denotes that data X is encrypted by key 
K using a given cipher algorithm C. {Y,Z} denotes that X 
and Z are elements in the request or reply PDU's. The 
meaning of the abbreviations is explained below. 

sid: session id 

RID: Request ID 

V: Version of the SUGP protocol 

C: Cipher Choice (e.g., no Encryption, RC5, RC2) 

devType: device type information 

crid: current request id 

SIDupl: session id for UP.Link. It is 4 byte long. 

NONCEb: nonce generated in browser. 

NONCEb: nonce generated in UP.Link. 

SUM: check sum for the entire request or reply for 

message integrity. 
DevId: device id 

Ksh: the shared secret key between the browser and 
URLink 

KUPL: the session key issued by UP.Link. 

1. The browser initiates a session creation request by first 
creating a client proto -session with NONCEb, and resetting 
the current request id (crid) to 0. 

2. The browser sends a Session Request to UP.Link. The 
sid is set to 0 to indicate that this is a Session Request. The 
browser sends all the information necessary to establish a 
session with UP.Link, including cipher choice, device type, 
and version information. To authenticate the server, the 
browser also sends NONCEb to challenge the server in the 
request. 
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3. Upon receiving the Session Request, URLink reads the If there are no Home URL and time request, the device 
plaintext portion of the requests. The plaintext fidds are sends GetNotify PDU to fetch the pending 
shown in the diagram. Using Devid as an index, URLink notifications, if any; the notification content is sent to 
looks up Ksh. Once Ksh is found, a proto-session is created. client in Notify Reply; 

URLink generates a session id, a key for the session, and S If there are home URL and/or time request, the device 

NONCEuPL to challenge the browser for authentication. sends ExtSrvRqst PDU with status set to SYNC, 

URLink also saves all information in the request for the which makes URLink to check if there is notification 

session. pending. If so, the status is set to NTFY in ExtSrvR- 

4. URLink sends reply to the browser with session key, ply PDU to indicate pending notifications, 
session id, bootinfo, and the challenge (NONCEupl), lO Multiple Notificatioas 

5. At this point, the browser checks the challenge for If there are multiple notifications pending for a subscriber, 
URLink and authenticate that URLink is really URLink ^t^tus can be set to NTFY in Notify Reply to indicate 
which holds its shared key Ksh. The browser then creates the j^ore to fetch. This makes a chained fetching of noti- 
session and saves the server session id and the session key fications possible* 

for the future r^uests The browser also increments the 15 ^ piggybacked in the next Get Notify PDU to 

current request Id (end). ack the recent of the last Notify Reply in case of a 

6. The browser must respond to URLink s challenge to u • j * u 
, . . L . . . . , ... chained retch. 

authenticate itself that the browser is the browser which 2 5 6 Errors 

holds aie sharedsect6tkey K.h The browser may optionally yp^j^ ^rror PDU's to an UP>Browscr if it 

piggyback a request to UP.Unk for process^ 20 ^^^^^ ^ 

7. URLink authenticates the browser at this point. If the include* 
browser is authenticated, the session is created; otherwise, ™^ inc u • 

the corresponding proto-session is discarded. If there is an Security violation (e.g., authenUcation failure, message 

pre-existing session with the browser, that session is auto- i & " ^ h 

matically terminated. 25 Security unavailable (e.g., service down) 

8. If a piggybacked request is attached, URLink process Unauthorized access (e.g., user/password required); 
the request. Invalid session (e.g., session expired); 

9. URLink sends reply to the browser. Invalid service request (e.g., non-exist service URL); 

10. The browser sends an ack to URLink. After this point, Unsupported version or cipher; 

normal requests follow. 30 r^ • * • j / * - • a\ 

^ ^ -> ' n ^ 1 Device not recognized (e.g., not provisioned) 

2.5.3 Device Power On w j c \ j c / u a 

„ , „ 1. f .1. J f n 1. J • For complete definition and error codes, refers to sugp.n. An 

See als o NoUricationssub -6 ertion for the default action when a device powers • • * ' r^^^ 

error scenario is shown m Flu. 35. 

The device is expected to cache sessions. If the device 2.5.7 Cancellation 

does not cache sessions, the session will be created before URBrowser may cancel a request at a user's demand. A 

any requests can be served. At the power on, the device cancellation scenario is shown in FIG. 36, 

normally has the following three ta^ to perform in one 2.5.8 Security Violations 

single request: Security violations include authentication failure and 

get time, if the device does not have a persistent clock; message integrity failure. The authentication failure will 

get notification status; 40 ^^^^ ^""^^ ^^^^^^ terminate the proto- 

get home URL, if necessary; immediately. The message integrity failures are 

FIG. 30 shows typical SUGP protocol interactions at power handled below: ^ , 

When the number of violations exceeds the configurable 

2.5.4 Client Requests limit, the server will terminate the session by either 
The simplest chent request form is sending request to 45 marking the session as invalid or remove the session 

URLink with an existing session. Because the session ^^^^ ^rom the session table. 

between the URBrowser and URLink already exists, a The client will request a new session after the number of 

service request can be sent directly to URLink. FIG. 31 security violations exceeds the limit, llie limit is server 

shows a normal request process with an existing session. configurable and is sent to client as one of the attributes 

If there is no session established yet, the browser initiates 50 in the Session Reply PDU. 

a session creation with the URLink, and optionally sends its 2,6.0 Secure Message Manager 

first service URL request together with Session Complete Secure Message Manager (SMM) provides the following 

request. Once the session is established, the client can make functionality: 

as many service URL requests until the session expires. RG. Encrypt/decrypt SUGP protocol PDU's; 

32 shows requests process without an existing session. ss Compression; 

If service credential is required, URBrowser will re-send Validate the message integrity; 

the service request with the required credential (e.g.,. UID/ Support multiple ciphers; 

Password) upon receiving a "Unauthorized Access" error generates an SMM Attachment for every SUGP PDU. 

PDU, which contains an error deck with the URL. A service An SMM Attachment is shown in FIG. 37. The role of the 

re-send process when service credential is required is shown eo attachment is for implementing the above functionality. The 

in RG. 33. gp^p^ Attachment consists of: 

2.5.5 Notifications Check-Sum: 4 byte^ check sum of the entire SUGP 
URLink Messenger mitiates the noUfication process by protocol PDU. It is encrypted. 

sending a SIGNAL to the client. The entire process is shown 2 ^ smaller PDU's, check-sum can be 2 bytes to limit the whole PDU in one 

below. A notification process is shown in FIG. 34. 65 block (8 bytes) 

Special Situations: IV: 2 bytes Initialization Value. It is always in plaintext. 

Device Power On or Switch from Voice to Data It is used to support block cipher in CBC mode with 
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Initialization Vector. IV is used to construct an initial- 
ization vector of block size. IV in this case is a nonce 
associated with a session. 

2.6.1 Encryption/Decryption 

SMM encryption/decryption has the following character- 
istics: 

No data expansion. 
Padding Rules: 

If the last block is less than the standard block size (8 
bytes), it will be added to X number of random bytes, 
where LastBlock+X=8. 

2.6.2 Compression 

SMM performs compression before encryption and 
decompression after decryption. Version 2.0 may not imple- 
ment this feature. The compression is one-way: UP.Link 
compresses data and the browser decompresses it to limit 
code/heap space under budget. 

Compression will be performed on digest and bootiiifo 
fields of the reply PDU's. The browser may store the 
compressed data as is and decompress them on demand. 

To take advantage of compression, compression is per- 
formed only if the data length exceeds the threshold. The 
high bit in the type field of PDU body may be used to 
indicate if the data is in fact compressed. 

2.6.3 Message Integrity 

SMM uses Check-Sum to enforce message integrity. The 
check-sum is taken cither 4 bytes or 2 bytes, depending on 
the PDU type. XOR is used to construct the check-sum. 

2.6.4 Multiple Cipher Support 

SSM can support multiple ciphers, but Version 2.0 
expects only one cipher algorithm. The device is expected 
only one cipher algorithm and it indicates to the server its 
algorithm and the parameters for the algorithm (e.g., rounds 
for RC5) at session creation. 

The server SSM must support multiple cipher algorithms. 
It pick up dynamically the appropriate cipher algorithm as 
required. 

2.6.5 Encryption Performance 

In order to improve encryption performance, the cipher 
algorithm implementation (normally in C) for a device may 
be converted to the assembly language code for the device. 
In general, such conversion has significant performance 
improvement. 

2.6.6 Encryption Algorithm 

Version 2.0 will use RC5 as the encryption algorithm 
between UP.Browser and UP.Link. RC5 will be used for: 
Authentication 
Message Privacy 
The reasons to select RC5 over RC4 

RC5 is small and fast; not as small as and as fast as RC4, 
but it is all we can find as an alternative for RC4 in 
terms of code size and speed. The code size of IDEA is 
not small. 

RC5 is a block cipher so that synchronization between 
UP.Browser and UP.Link is not required. This is ideal 
for our basic architecture on UDP becatise UDP is not 
a reliable transport. 

Although RC4 can be configured to handle message 
losses, the overhead and complexity for loss recovery 
is very significant. 

RC4 requires at least 516 bytes of persistent storage for 
storing its states (S-boxes) if the shared secret key can 
be used for creating many sessions over a long period 
of time (e.g., 4 years). 

RC5 is part of RSA*s BSAFE product, the most reputable 
encryption product in the world. Although it is new and 
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about 2 years of life, RSA expects that it will be 
accepted widely. RSA recommends RC5 over RC2 
because it is fast and safer than RC2. RC2 is currently 
used in many commercial products. 
5 RC5 parameters 

RC5 is parameterized as w/r/b, 
w: logical word size in bits; block size is 2*w; 
r: number of rounds; 
b: number of bytes in the key; 
10 The higher r, w, and b will provides higher security. 
However, higher r and w requires more computation time. 
RSA recommends 32/12/16. The parameters will be deter- 
mined for V2.0 as the following: 
w: 32 bits. This implies the block size is 64 bits (8 bytes). 
15 r: minimum 16. 

Server should accept r values between 12-R, where 

12<R<255 is a server configurable parameter; 
Client is configurable at provisioning time when the 

shared secret key is provisioned; 
Session creation uses 32 rounds for higher security to 
protect the permanent shared secret key and the current 
session key exchange; 
b: 16 bytes. 

5 bytes for international market as required by U.S. 
Export Law. 
2.7.0 Dependencies 
Encryption Libraries 
Source code Hcenses for RC5. This is an external 
dependency. 
Difl&e-Hellman Library 
This is an external dependency. We may need DifiBe- 
Hellman key exchange protocol to perform auto- 
matic configuring. The source code license is 
35 required, Diffie-Hellman patent will expire on Apr. 

29, 1997. 

Nonce and Random Number Generation for the Device 
To implement authentication, nonce should be gener- 
ated in the device. Nonce does not require 
40 randomness, but requires uniqueness over a long 

time period (e.g., during Ufe time of a shared secret 
key), we expect that the Qient Group provides 
support for implementing the nonce. 
If Diffie-Hellman is adopted, random number genera- 
45 tion is also required. 

Device Dependent Driver for UDP 
This is the interface for UDP protocol layer. Although 
PCSI and Mitsubishi phones already have device 
dependent drivers for UDP, which do not require any 
50 changes for Magellan, the Client Group is expected 

to provide the device dependent UDP drivers if we 
move to new platforms. 
Session Creation and Session Context Management 
Both the Browser and the UP.Link must create sessions 
55 and maintain session contexts, which contains such 

items as session keys. Although UP.Browser only 
has one session, the notion of session exists. 
2.8.0 Backwards Compatibility Impact 

This version of SUGP protocol is not designed to be 
60 compatible with the previous version of the protocol (e.g., 
UGP) which is used in the version 1.1 and earlier UP 
products. If the customers want to run previous version of 
browsers, they are assumed to keep the previous version of 
UP.Links operational. 
65 However, the protocol provides a version control mecha- 
nism so that the protocol may be implemented both back- 
ward compatible and forward compatible in the future. 
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2.9.0 Performance Impact 

Due to the overhead for encryption and decryption in both 
UP. Browsers and URLinks. It is expected that the system 
will be slower if it is measured in milliseconds. However, 
the slowdown may not be significantly noticeable by the s 
browser users. 

According to our own bench marking test for RC5 32/16/ 
16, a single CPU SUN Ultra is able to encrypt (or decrypt) 
1000 KB data per second. If we assume the following: 
phone device is 250 times slower than an Ultra in speed, 10 

which implies 4 Kbytes encryption per second; 
average user makes a request every 3 seconds with 

average data 300 bytes; 
UP.Link is configured such that a single Ultra CPU will 

handle 100 requests / sec; 
RC4 is used for SSL. RC4 can nm 2 times faster than 

RC5; 

We may have the following estimation of performance 
overhead: 

phone devices may have 2.5% overhead, which means 
that for every 3 seconds time interval, 0.075 seconds or 
75 milliseconds are used for encryption. 
UP.Link may have total 4.5% overhead, which includes 
both encryption between the phone device and UP.Link and 
encryption between the UP.Link and the service (Web). That 
overhead means that for every second, the UP.Link spends 
0.05 seconds or 50 milliseconds to perform encryption. 
What is claimed is: 

1. A method for processing data pushed over a network 
from a data source or sources to a data destination or 
destinations via a computer system intermediate between the 
source or sources and the destination or destinations, 
wherein the intermediate computer system communicates 
with the source or sources and destination or destinations 
over the network, the method comprising: 

the intermediate computer system receiving data being 
pushed from a data source to a data destination DEI; 

if the intermediate computer system is unable to forward 
the pushed data to the destination DEI for a predeter- 40 
mined length of time, then the intermediate computer 
system deleting the pushed data and never forwarding 
the pushed data to the destination DEI. 

2. The method of claim 1 further comprising the destina- 
tion DEI pulling the data that has been pushed to the 45 
destination but deleted at the intermediate computer system. 

3. A computer system comprising circuitry and one or 
more computer instructions for serving as an intermediate 
computer system through which data are pushed over a 
network from a data source or sources to a data destination 50 
or destinations wherein the intermediate computer system 
communicates with the source or sources and destination or 
destinations over the network, the circuitry and the one or 
more computer instructions being for: 

the intermediate computer system receiving data being S5 
pushed from a data source to a data destination DEI; 

if the intermediate computer system is unable to forward 
the pushed data to the destination DEI for a predeter- 
mined length of time, then the intermediate computer 
system deleting the pushed data and never forwarding 60 
the pushed data to the destination DEI. 

4. A computer readable medium comprising one or more 
computer instructions for being executed by an intermediate 
computer system through which data are pushed over a 
network from a data source or sources to a data destination 65 
or destinations, wherein the intermediate computer system 
communicates with the source or sources and destination or 
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destinations over the network, the one or more computer 
instructions being for: 

the intermediate computer system receiving data being 
pushed from a data source to a data destination DEI; 
if the intermediate computer system is unable to forward 
the pushed data to the destination DEI for a predeter- 
mined length of time, then the intermediate computer 
system deleting the pushed data and never forwarding 
the pushed data to the destination DEI. 

5. The method of claim 1 wherein the destination DEI is 
a mobile device. 

6. A method for processing data pushed over a network 
from a source or sources to a destination or destinations via 
a computer system intermediate between the source or 
sources and the destination or destinations, wherein the 
intermediate computer system communicates with the 
source or sources and destination or destinations over the 
network, the method comprising: 

the intermediate computer system receiving data being 
pushed to a destination DEI; 

the intermediate computer system receiving a command 
to delete the data if the data has not yet been forwarded 
to the destination DEI; 

if the data has not yet been forwarded to the destination 
DEI, then the intermediate computer system deleting 
the data and never forwarding the data to the destina- 
tion DEI. 

7. The method of claim 6 wherein the command is 
received over the network from a source that was pushing 
the data. 

8. A computer system comprising circuitry and one or 
more computer instructions for serving as an intermediate 
computer system through which data are pushed over a 
network from a source or sources to a destination or 
destinations, wherein the intermediate computer system 
communicates with the source or sources and destination or 
destinations over the network, the circuitry and the one or 
more computer instructions being for: 

the intermediate computer system receiving data being 
pushed to a destination DEI; 

the intermediate computer system receiving a command 
to delete the data if the data has not yet been forwarded 
to the destination DEI; 

if the data has not yet been forwarded to the destination 
DEI, then the intermediate computer system deleting 
the data and never forwarding the data to the destina- 
tion DEI. 

9. A computer readable medium comprising one or more 
computer iastructions for being executed by an intermediate 
computer system through which data are pushed over a 
network from a source or sources to a destination or desti- 
nations wherein the intermediate computer system commu- 
nicates with the source or sources and destination or desti- 
nations over the network, the one or more computer 
instructions being for: 

the intermediate computer system receiving data being 
pushed to a destination DEI; 

the intermediate computer system receiving a command 
to delete the data if the data has not yet been forwarded 
to the destination DEI; 

if the data has not yet been forwarded to the destination 
DEI then the intermediate computer system deleting 
the data and never forwarding the data to the destina- 
tion DEI. 

10. A method for processing data pushed over a network 
from a source or sources to a destination or destinations via 
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a computer system intermediate between the source or 
sources and the destination or destinations, wherein the 
intermediate computer system communicates with the 
source or sources and destination or destinations over the 
network, the method comprising: 5 
the intermediate computer system receiving data DAI 
being pushed to a destination or destinations, wherein 
the pushed data DAI includes an identifier identifying 
a source of the ptished data; 
if the identifier of the pushed data DAI matches an 
identifier of data pushed earlier to the same destination 
or destinations but not yet forwarded to at least one of 
its destination or destinations, then the intermediate 
computer system deleting the earlier pushed data and 
never forwarding the earlier pushed data to the desti- 
nation or destinations. 

11. The method of claim 10 wherein the data DAI is a 
more recent version of the earlier pushed data. 

12. A computer system comprising circuitry and one or 
more computer instructions for serving as an intermediate 
computer system through which data are pushed over a 
network from a source or sources to a destination or 
destinations, wherein the intermediate computer system 
communicates with the source or sources and destination or 
destinations over the network the circuitry and the one or 
more computer instructions being for: 

the intermediate computer system receiving data DAI 
being pushed to a destination or destinations, wherein 
the pushed data DAI includes an identifier identifying 
a source of the pushed data; 

if the identifier of the pushed data DAI matches an 
identifier of data pushed earlier to the same destination 
or destinations but not yet forwarded to at least one of 
its destination or destinations, then the intermediate 35 
computer system deleting the earlier pushed data and 
never forwarding the earlier pushed data to the desti- 
nation or destinations. 

13. A computer readable medium comprising one or more 
computer instructions for being executed by an intermediate 
computer system through which data are pushed over a 
network from a source or sources to a destination or 
destinations, wherein the intermediate computer system 
communicates with the source or sources and destination or 
destinatioas over the network, the one or more computer 45 
instructions being for: 

the intermediate computer system receiving data DAI 
being pushed to a destination or destinations, wherein 



the pushed data DAI includes an identifier identifying 
a source of the pushed data; 
if the identifier of the pushed data DAI matches an 
identifier of data pushed earlier to the same destination 
or destinations but not yet forwarded to at least one of 
its destination or destinations, then the intermediate 
computer system deleting the earlier pushed data and 
never forwarding the earlier pushed data to the desti- 
nation or destinations. 

14. A method for operating a server to provide data over 
a network, the method comprising: 

the server pushing data to a data destination or destina- 
tions by sending the data over the network to an 
intermediate computer system which is to forward the 
data over the network to the data destination or desti- 
nations; and 

the server sending a command to the intermediate com- 
puter system to delete data which the server pushed 
earlier, the command being a command to delete the 
data if the data has not yet been forwarded to its 
destination. 

15. The method of claim 14 wherein at least one of the 
destinations whose data are to be deleted if not yet for- 
warded is a mobile device. 

16. A server programmed to perform the following opera- 
tions: 

pushing data to a data destination or destinations by 
sending the data over a network to an intermediate 
computer system which is to forward the data over the 
network to the data destination or destinations; and 

sending a command to the intermediate computer system 
to delete data which the server pushed earher, the 
command being a command to delete the data if the 
data has not yet been forwarded to its destination. 

17. A computer readable medium comprising one or more 
computer instructions for causing a server to perform the 
following operations: 

pushing data to a data destination or destinations by 
sending the data over a network to an intermediate 
computer system which is to forward the data over the 
network to the data destination or destinations; and 

sending a command to the intermediate computer system 
to delete data which the server pushed earlier, the 
command being a command to delete the data if the 
data has not yet been forwarded to its destination. 
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